Subject: [midcom] Expressiveness of Filtering Expression (was RE: [midcom] policy & duration

From: Jiri Kuthan <[email-masked]>
Date: Thu, 09 Aug 2001 18:28:38 +0200

At 02:37 AM 8/9/2001, Reinaldo Penno wrote:
>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.

Could you give me a specific example of an application where a 5-tuple is clearly not 
enough? My personal opinion is that staying simple is good and if someone desires
higher complexity the burden is on him/her to show the need for it.

-Jiri, the believer in "5-tuple is good enough for removing ALGs from middleboxes"

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

---

From: Andrew Molitor <[email-masked]>
Date: Thu, 9 Aug 2001 12:52:51 -0500 (CDT)

WARNING: I am about to diverge into implementation. Please
consider me pre-chastised, and these comments to be random chitchat.

	I'd rather avoid having MIDCOM include some sort of complicated
syntax for describing packets. On the other hand, it's clearly useful to
go beyond 5-tuples for pinholes. Supporting such a syntax is potentially
and implmentation nightmare, since the middlebox implementor has to
build a compiler to convert it into middlebox native filtering.

	Thus, I'd like to see pinholes specified with something like:

	- a 5 tuple (masked)
	- a time to live (of some sort -- see earlier discussions for
	  the ugly problems HERE)
	- a syntactical cookie of the form, e.g. RTP or RTP(256)

	The syntactical cookie would mean 'this pinhole applies to
RT traffic, so if you happen to know anything about what RTP traffic
should look like, please do that'. The cookies might allow cookie-specific
parameters like maximum packet size or whatever.

	Then we could have a little cottage industry producing an endless
stream of RFCs (remember TCP options, I think telnet options, and
MIME types) which define new cookies and what their parameters mean,
together with suggestions for filtering logic to match them.

	A middlebox would ignore cookies it doesn't understand and just
use the 5-tuple.

	This seems to be a more nicely abstract interface, and a WHOLE
lot easier for a middlebox implementor, say, me, to do. The idea of
accepting tcpdump expressions and compiling them on the fly (or matching
them against existing patterns or something) fills me with horror and
dread.

		Andrew