Subject: RE: [midcom] requirements-01 status

From: "Fleischman, Eric W" <[email-masked]>
Date: Wed, 27 Jun 2001 15:08:20 -0700

Bob Penfield wrote:
>So it does not matter what physical interface a packet comes in on, if it
>matches the pinhole-descriptor it gets through. People are really OK with
>this? I don't think I could sell a firewall that allowed that to any IT
>manager I know.
>
>In the firewall that we have, you have to specify the source and destination
>interfaces (LAN, WAN, DMZ, or * for any) as well as source and destination
>IP addresses.

Wait a minute here, Bob. What this thread was talking about was
that the FlowDirection tuple of the Pinhole-Descriptor proposed
in Section 5.2.1 was redundant, and therefore should be eliminated.
I don't think that there is any agreement yet on whether the resulting
5-tuple is a complete Pinhole-Descriptor or not. Why doesn't the
list leverage your posting to discuss whether egress_port ingress_port
are also descriptor requirements or not -- or whether additional
information should be added to the descriptor. 

Question: If you are arguing that ingress_port and egress_port should 
be part of the descriptor, how will the Midcom Agent know that type 
of information -- and need it know it?

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

---

From: Andrew Molitor <[email-masked]>
Date: Wed, 27 Jun 2001 18:08:04 -0500 (CDT)

> information should be added to the descriptor. 

	There are at least two loosely related notions of directionality.
A pinhole description can usefully say 'traffic originating from
<this stuff> and going to <this other stuff>' as a unidirectional
pinhole specification. By replacing the word from with the phrase 'to or
from' the pinhole becomes the bidirectional equivalent. Of course,
<this stuff> and <this other stuff> are just some sort of endpoint
specifications, in general.

	The other, related, notion we've been worrying about is
whether <this stuff> and <this other stuff> might not include
interface names. That is, do we allow interface identifiers to be part of
an endpoint description?

	[ this is, I think, the substance of Eric's remarks, rephrased
	  in my own witty informal way. Right? ]

	There is a school of thought that says if the endpoint
specifications include IP address, then interface information is redundant
since everyone does IP address checking at the interface itself. Therefore
the source IP address can only come from a specific interface, and a
destination IP address can only be going to a specific interface, so
why bother calling out the interfaces explicitly?

Point 1:
	it is without a doubt a requirement to allow specification of
	unidirectional pinholes (see below), that is to say 'from A
	going to B, but not from B going to A' in a pinhole specification.

Point 2:
	If you don't happen to know the IP addresses, it may well be
	useful to associate an interface name in the endpoint, so you
	don't have to say 'from anyplace to B', you can instead say, in
	effect 'from anyplace outside to B' or more usefully 'from
	anyplace on the DMZ to B.' It's not obvious to me that this
	is vastly useful, but it seems superficially an improvement.

Why Point 1:
	In IP Telephony, your pinholes always look like 'allow
UDP traffic from anywhere to <this address/port>'. If this implies
the opposite direction of flow, you get: 'from <this address/port> to
anywhere' as also permitted. This means that if I want to break into
your network, all I have to do is call you, and keep you talking.
I can then send UDP packets from my 'phone' into anywhere at all
in your network.