Subject: RE: [midcom] policy & duration

From: "Fleischman, Eric W" <[email-masked]>
Date: Thu, 9 Aug 2001 00:58:48 -0700

If a five tuple is not enough information to identify a pinhole, what would be enough?

> ----------
> From: 	Reinaldo Penno[SMTP:[email-masked]]
> Sent: 	Wednesday, August 08, 2001 5:37 PM
> To: 	'Andrew Molitor'; [email-masked]'
> Subject: 	RE: [midcom] policy & duration
> 
> Hello Andrew,
>  
> just adding some points on what we disucssed based on my reading of the charter...
>  
> IMO MIDCOM should be a protocol that is general or extensible enough so that I can inform the firewall how to identify, for instance, RTP packets or more generally offsets as you said. 
>  
> It seems some people only want to solve specifically "how to pass SIP through a firewall". This is very evident from the fact that some people think 5 tuple is enough. If we are thinking about getting any type of ALGs from the middlebox, put on a MA and still have the same funcionality, clearly this is not enough.
>  
> The charter of the group is very generic. If what we want to solve is how to pass SIP through a firewall, then we need to change  the charter to something like "SIP Firewall Transversal Group", cause we are clearly not making it general/extensible enough.
>  
> thanks,
>  
> Reinaldo
> 
> 	-----Original Message-----   
> 	From: Penno, Reinaldo [SC9:T327:EXCH] 
> 	Sent: Wednesday, August 08, 2001 5:06 PM
> 	To: 'Andrew Molitor'; [email-masked]'  
> 	Subject: RE: [midcom] policy & duration
> 
> 
> 
> 	Hello Andrew, 
> 
> 	>       I think it's important to figure out what those essential 
> 	> interactions are between your SIP code and the routing processes, 
> 	> interface manager, firewall, etc. Presumably the SIP code interacts 
> 	> with many things non-SIP, some of those things are sort of 
> 	> network-ish, 
> 	> and some of THOSE things might naturally fall into a middlebox. 
> 	> 
> 	>       Whatever interactions can be reasonably imagined between 
> 	> say, SIP code and such middleboxy non-SIP things should be well 
> 	> understood before we go much further. The point of MIDCOM is, to 
> 	> first order, to develop a protocol expressive enough to capture 
> 	> those interactions. If we fail to produce something powerful enough 
> 	> for, say, the SIP community, we have failed entirely. 
> 
> 	We are in agreement. 
> 
> 	> 
> 	>       I don't actually know what, apart from 5-tuples and masks 
> 	> for them needs to get carted around in these interactions. That much 
> 	> information seems to work fairly well for pinholes and NAT bindings, 
> 	> at any rate. Well, it's nice to be able to carry around things 
> 	> like expected bandwidth and pinhole lifetime and whatnot, is this 
> 	> the kind of thing you mean? 
> 
> 	I simpler example is interface. 
> 
> 	Or do you want to open a pinhole for 
> 	> RTP traffic, and be able to specify approximately what RTP traffic 
> 	> looks like BEYOND 'UDP traffic from that place to this other place'? 
> 
> 	Yes. 
> 
> 	> Things like size of packet, expected values at expected offsets in 
> 	> the payload? 
> 
> 	Yes. 
> 
> 	thanks, 
> 
> 	Reinaldo 
> 
> 

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

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 9 Aug 2001 04:31:08 -0400

----- Original Message -----
From: "Fleischman, Eric W" <[email-masked]>
To: "'Andrew Molitor'" <[email-masked]>; <[email-masked]>; "'Reinaldo
Penno'" <[email-masked]>
Sent: Thursday, August 09, 2001 3:58 AM
Subject: RE: [midcom] policy & duration

> If a five tuple is not enough information to identify a pinhole, what
would be enough?

ingress realm (interface or set of interfaces on which the packets will
arrive)
source address or address mask or address prefix
source port or range of ports
destination address or address mask or address prefix
destination port or range of ports
transport protocol

These would constitute a ruleset-descriptor (or flow-descriptor).

An egress realm (interface or set of interfaces on which the packet should
be sent out) would be part of a ruleset-action (as in "forward packets to
address X in realm Y")

> > IMO MIDCOM should be a protocol that is general or extensible enough so
that I can inform the firewall how to identify, for instance, RTP packets or
more generally offsets as you said.
> >
> > It seems some people only want to solve specifically "how to pass SIP
through a firewall". This is very evident from the fact that some people
think 5 tuple is enough. If we are thinking about getting any type of ALGs
from the middlebox, put on a MA and still have the same funcionality,
clearly this is not enough.
> >
> > The charter of the group is very generic. If what we want to solve is
how to pass SIP through a firewall, then we need to change  the charter to
something like "SIP Firewall Transversal Group", cause we are clearly not
making it general/extensible enough.

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 9 Aug 2001 06:03:16 -0400

> From: "Bob Penfield" <[email-masked]>
 
> destination port or range of ports

I think we need to allow for extremely general filter descriptions,
which may include well-understood things like protocol and port
number but which may also include arbitrary length data at arbitrary
offsets.  Consider the bpf filter machine.

Melinda

---

From: Mark Duffy <[email-masked]>
Date: Thu, 09 Aug 2001 09:57:44 -0400

At 04:31 AM 8/9/01 -0400, Bob Penfield wrote:
...
>be sent out) would be part of a ruleset-action (as in "forward packets to

I *strongly* disagree with the ingres/egress realm parts of that.  Where to
forward the packet should be left (at least sometimes, in some MB's) up to
an IP forwarding (BMP) decision.

Rather, I believe the n-tuple should specify realm (or interface) and
direction (relative to the realm or interface).  Here is why:  In a
generalized case MB with multiple interfaces connecting to multiple realms,
packets may flow from one private realm to another, or from a private realm
to/from the Internet realm, etc.  The MB in such cases should independently
apply MB policy of the realm from which a packet came, followed by MB
policy for the realm to which the packet is going. 

The 2 policies can be independently represented by separate n-tuples: one with
 realm = RealmA, direction = incoming,   and the other with
 realm = RealmB, direction = outgoing
The first would apply the associated actions to matching packets arriving
at the MB from RealmA, and the second would apply the associated actions to
packets flowing to RealmB.

--Mark