Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 17 Apr 2002 12:27:24 -0400

Unfortunately the IP address is NOT known in many of those scenarios.

-----Original Message-----
From: Martin Stiemerling [mailto:[email-masked]]
Sent: Wednesday, April 17, 2002 11:19 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: [email-masked]
Subject: Re: [midcom] MIDCOM SEmantics: Policy Rule Content

Tom-PT Taylor wrote:

> I agree that the double wildcarding goes a bit far, but most of the
> scenarios in Christian's document require wildcarding at one end or the
> other.

Some wildcarding will be required for sure, but setting the IP address
and the port number to wildcard is too much wildcarding, i.e. especially 
the sys admins won't like this.
A good wildcarding situation would be that the IP address is known, but 
not the specific port number.

Martin

> 
> -----Original Message-----
> From: Juergen Quittek [mailto:[email-masked]]
> Sent: Monday, April 15, 2002 9:50 AM
> To: Taylor, Tom-PT [CAR:B800:EXCH]; 'Jiri Kuthan'; 'Martin Stiemerling';
> Sen, Sanjoy [NGC:B692:EXCH]
> Cc: [email-masked]; Aoun, Cedric [QPD:MA01:EXCH]
> Subject: RE: [midcom] MIDCOM SEmantics: Policy Rule Content
> 
> 
> Hi Tom,
> 
> --On 12 April 2002 08:51 -0400 Tom-PT Taylor <[email-masked]>
> wrote:
> 
> 
>>I agree with your distinction between the issues of rule overlapping and
>>
> access control.  I do wonder if you are being too dogmatic on the matter
of
> rule overlapping, and would beg for exceptions in two cases:
> 
>>  -- the rules do not involve contradictory actions (e.g. both rules allow
>>
> flows)
> 
>>  -- the rules both come from the same Agent.
>>
>>Here is an example scenario in which I could see the possibility of rule
>>
> overlapping: a rule is set up allowing any node inside to connect to a
> specific address outside.  Then an Agent sets up a rule allowing
connection
> from a specific inside address
> 
>>to that outside address.  In the process, the Agent receives an address
>>
> binding to the mapped address at the Middlebox.  Using the notation I have
> proposed earlier, the first rule is:
> 
>>Filter= { Source address:      ANY,
>>          Source port:         ANY,
>>          Source realm:        <the internal realm>,
>>          Map address:         ANY,
>>          Map port:            ANY,
>>          Map realm:           <the external realm>,
>>          Destination address: <specific external address>,
>>          Destination port:    <specific external port>,
>>          Destination realm:   <the external realm>,
>>          Protocol             <a specific protocol> },
>>
>>Action = Allow
>>
> 
> Maybe I'm wrong, but I consider this kind of rule to be out of scope of
> midcom. This colesction of wildcards looks like an administrative NAT
> configuration but not like something that an application requires.
> 
>     Juergen
> 

-- 
Martin Stiemerling

NEC Europe Ltd. -- Network Laboratories  [email-masked]
IPv4: http://www.ccrle.nec.de  IPv6: http://www.ipv6.ccrle.nec.de

_______________________________________________
midcom mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/midcom

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 18 Apr 2002 10:24:30 +0200

> Unfortunately the IP address is NOT known in many of those scenarios.

Yes and no. The scenarios in section 2.1 won't be considered anymore, as 
far as I know. Because they belong more to the middle box management and 
not to open dynamically pin holes.
In some applications the IP address isn't really know, e.g. SIP. You 
know only the listing part (address + port number) of each participant, 
the sending IP address + port number is free too choose. But in 99.999 % 
  of the IP telephony cases I would assume that the IP address of the 
sending part has the same IP address as the receiving part. With this 
information you know the IP address.

Martin