Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt

From: "Christian Huitema" <[email-masked]>
Date: Fri, 22 Jun 2001 17:34:31 -0700

First, the obvious. The draft appears to not be written in ASCII --
there are quite a few strange characters in it. Could someone fix that?
Also, could someone fix the title? This should be strictly a protocol
requirement document, not a "protocol architecture" document.

Next comment concerns the figure on page 6. The "Application Control
Flow" line should be removed. It it a throw back of the "OOP" debate; we
debated that OOP should maybe be mentioned in the framework with due
precautions; it certainly does not belong in the requirements.
Similarly, the paragraph that states that "The Middlebox must support
the explicit forwarding of application control session information"
should be removed, as well as the whole of section 7.

Section 5.1 has a paragraph about direction, essentially stating that
flows should be directional. I don't think that we have any consensus on
this. Indeed, if you look at the scenario documents, there is not a
single example in which directional flows could be useful. Do we really
want to enable communication one way without enabling it the other way?
I think that this paragraph should be removed from the requirements.
Similarly, flow direction should be removed from the pin-hole
requirements in section 5.2.

On pin-hole requirements, page 8, the reference to "netmask" should be
replaced by a reference to subnet prefix; for IPv6, the reference should
be to "payload type" rather than "next header type." The paragraph on
direction shall be removed. The reference to TOS bits is questionable --
if this is a requirement to the protocol, we have better make sure that
using or heeding such specification is optional.

The role of section 8 is debatable. There is no requirement for any of
the "Application Content Flow Services" in any of the scenarios.

At a more general level, I find that the document is poorly organized,
and is by no means a complete requirement document. Both section 5,
General Protocol Requirements, and section 6, Agent and Middlebox
association, fall in the classic mistake of explaining "how" rather than
explaining "what", i.e. proposing an architecture rather than proposing
an actual list of requirements. This is quite bad, since we loose a lot
of the rationales developed in the working group. The requirements
should be derived from the framework and the scenarios; in fact, the
scenario and requirement drafts should be merged. The requirement
themselves should be split in three sections, functional requirement,
i.e. how to pass enough data to make the scenario work, security
requirements, and operational requirements, i.e. how to meet various
performance and stability constraints.

-- Christian Huitema

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

---

From: Andrew Molitor <[email-masked]>
Date: Fri, 22 Jun 2001 20:29:26 -0500 (CDT)

> should be removed, as well as the whole of section 7.

	I seem to recall that:

	- OOP as a concept was voted down, or at any rate demoted to
	  a passing mention in the framework
	- a couple of people (my included) suggested that it should
	  be resurrected as a requirement for a packet diversion
	  function on par with Pinholes and NAT.

	If there was any substantial discussion on the latter, I missed
it.

> requirements in section 5.2.

	RTP media flows are in practice often unidirectional.
Yes, it is useful and desirable to allow one-way flows. The scenario
documents should be updated to reflect this, if they do not.

		Andrew

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 22 Jun 2001 22:39:52 -0400

See embedded comments

----- Original Message -----
From: "Christian Huitema" <[email-masked]>
To: <[email-masked]>
Sent: Friday, June 22, 2001 8:34 PM
Subject: RE: [midcom] draft-ietf-midcom-requirements-01.txt

> should be removed, as well as the whole of section 7.

I agree that section 7 is not needed, except the requirements in 7.1 (but
not 7.1.1) should apply for any kind of flow.

> want to enable communication one way without enabling it the other way?

Yes actually. The RTP flows set up by SIP are uni-directional. There will be
a separate pin-hole for each direction. Also, the pin-hole spec for RTP will
have to allow any source address to the destination address and port in the
SDP since SDP does not contain the source address for the RTP. In this case
I think knowing the direction of the flow can at least limit the "any source
address" to the side that we know the RTP packets for that flow should be
coming from.

---

From: "Melinda Shore" <[email-masked]>
Date: Sat, 23 Jun 2001 08:11:32 -0400

> documents should be updated to reflect this, if they do not.

It's not clear to me why directionality can't be expressed
in terms of source/destination.  I have a little trouble
with the concept of inside/outside.

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Sat, 23 Jun 2001 11:47:47 -0400

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Andrew Molitor" <[email-masked]>; <[email-masked]>
Sent: Saturday, June 23, 2001 8:11 AM
Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt

> with the concept of inside/outside.

I think direction is very important especially for middleboxes at the
borders between networks. If a middlebox is just a "bump on the wire" with
two network interfaces, packets arrriving at one interface that match a
pin-hole spec are sent out the other interface. In order to ensure the
desired packet forwarding/admission, the pin-hole would need to be
associated with the interface that the packets would be arriving on. Packets
arriving on the other interface that happen to match the source address
prefix/mask for that pin-hole spec would be blocked.

(-:bob

---

From: "Melinda Shore" <[email-masked]>
Date: Sun, 24 Jun 2001 08:02:03 -0400

> In order to ensure the

I think we're saying the same thing.  Given that
we've got source addresses and destination addresses
in the IP headers, isn't putting additional directionality
information redundant (and potentially confusing if there
are conflicts)?

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Sun, 24 Jun 2001 08:29:39 -0400

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Andrew Molitor"
<[email-masked]>; <[email-masked]>
Sent: Sunday, June 24, 2001 8:02 AM
Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt

> information redundant (and potentially confusing if there

I think you missed my point. What about a spoofed source address? Granted
that stops only one kind of attack on only one side of the middlebox. Also,
with all the multi-homing, redundant links and other kinds of complex
routing isn't it possible, if the middlebox represents the destination
address of a packet, that packets with the same source and destination could
arrive at either side. Maybe that's a stretch, but I'm not a routing expert.

If I am implementing a middlebox, being able to have a separate pin-hole
tables for each interface is more efficient. Theses boxes usually need to
operate at or near wire-speed.

(-:bob

---

From: "Melinda Shore" <[email-masked]>
Date: Sun, 24 Jun 2001 08:35:42 -0400

> I think you missed my point. What about a spoofed source address? 

Spoofed source addresses can be (and are today) handled by
ingress and egress filtering at the interface.  See sections 
4.3 and 4.4 of RFC 3013.

Melinda

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Jun 2001 00:40:51 -0700 (PDT)

Christian, WRT uni/bi-directional flows, do we need to insert a "Multicast
Considerations" section?

---

From: "Christopher A. Martin" <[email-masked]>
Date: Mon, 25 Jun 2001 10:09:45 -0500

I agree with Bob.

Rules are typically implemented per interface with source and destination
defined per interface. For the rule being configured the source and
destination is defined relative to the interface as this is related  to the
direction of the flow.

We could use the many terms such egress (inside) and ingress (outside)
[these specific associations being my view of reality], and as Bob states
with the example of IP spoofing, the tables are relevant to the interface,
and these tables are in use today by many vendors. In the case of IP
spoofing one of the best practices in the industry is in the definition of
ingress and egress filter rules to prevent IP spoofing from being possible.
These filters are applied to the specific interfaces in order to obtain the
desired results.

Even your own product defaults to the terms inside and outside when
describing interfaces.

I wish I had more time to elaborate here....

Chris
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Bob Penfield
Sent: Sunday, June 24, 2001 7:30 AM
To: Melinda Shore; Andrew Molitor; [email-masked]
Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: "Bob Penfield" <[email-masked]>; "Andrew Molitor"

(-:bob

---

From: "Melinda Shore" <[email-masked]>
Date: Mon, 25 Jun 2001 11:18:03 -0400

> In the case of IP

I'm trying to get a handle on why people feel that
using transport header source and destination addresses
along with per-interface policy isn't sufficient -
why do we need, for example, a "direction" field in
a midcom information element?  I'd like to avoid
redundancy and potential conflicts that result from
that redundancy.

Melinda

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 25 Jun 2001 15:01:45 -0400

----- Original Message -----
From: "Melinda Shore" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, June 25, 2001 11:18 AM
Subject: Re: [midcom] draft-ietf-midcom-requirements-01.txt

> redundancy and potential conflicts that result from
All I am saying is that we need to be able to associate a pin-hole spec with
the specific network interface (or set of interfaces if there are redundant
links) it should apply to. I don't think we need "direction" and
"interface", just some sort of "interface" field.

---

From: "Melinda Shore" <[email-masked]>
Date: Mon, 25 Jun 2001 15:30:45 -0400

> "interface", just some sort of "interface" field.

That makes more sense, but I think we need to work 
through how the agent knows what the interfaces
are on the box, and how it makes use of that knowledge.
That's starting to get into routing.

Melinda

---

From: Andrew Molitor <[email-masked]>
Date: Mon, 25 Jun 2001 16:14:35 -0500 (CDT)

> That's starting to get into routing.

	It's actually kind of awful how much the Agent needs to
know about the middlebox.

	The issue of 'discover' versus 'configure' has been raised
a few times. Is it extremely desirable to have the middlebox able to
spill its guts vis-a-vis:

	- capabilities (NAT, pinholes, etc)
	- interfaces
	- plumbing (NAT after pinholes, NAT before pinholes, etc)
	- other?

	via MIDCOM, or is it acceptable or desirable to force this
information to be configured into the Agent?

	Note that the 'discover' model is easy for middlebox vendors,
since it's pretty much just serving up some static answers to one or
more query methods. Figuring out what to DO with the information is
a tricky one for the Agent, but it probably the same problem whether
configured manually, or discovered. It's probably a little harder if
discovered because there's no good way to punt. If the user is configuring
it by hand, the Agent's GUI can just pop up a 'That won't WORK!' window
by way of punting.

---

From: "Melinda Shore" <[email-masked]>
Date: Tue, 26 Jun 2001 08:10:53 -0400

> From: Andrew Molitor <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, June 25, 2001 5:14 PM

> information to be configured into the Agent?

Discovering middleboxes in the network is out of scope; discovering
capabilities of "found" middleboxes is not.  Nevertheless I think
we're heading into the weeds and that we should stop.  Our charter
is limited and while we need to keep extensibility a priority we
really should not be loading up on defined features that don't
have applicability to the problem at hand.

If someone really, really believes that we need to know what
the interfaces on a middlebox are in order to support application
traversal, they should explain 1) the problem they feel it solves, 
2) why they feel it solves it, and 3) which other possible approaches 
to solving the problem were considered and rejected.

Melinda