Subject: [NSIS] draft on middlebox communication and NSIS

From: Marcus Brunner <[email-masked]>
Date: Mon, 24 Jun 2002 21:18:01 +0200

I interpreted the cut-off time wrong (9:00) though to be in the evening)
Nevertheless, those of you interested in middlebox communication, here is a 
short text on middlebox communication in the NSIS framework.

http://www.brubers.org/marcus/papers/draft-brunner-nsis-mbox-fmwk-00.txt

Marcus
--------------------------------------
Dr. Marcus Brunner
Network Laboratories
NEC Europe Ltd.

E-Mail: [email-masked]
WWW:    http://www.ccrle.nec.de/
personal home page: http://www.brubers.org/marcus

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 25 Jun 2002 09:57:46 +0100

Hi Marcus,

I like this draft a lot. Especially since, following recent scope discussions, we've been supposed to think about NSIS != QoS signalling but broader, but all our instincts about the top level way the protocol should operate are clearly still driven by QoS-derived thinking (although we did our best to make the latest framework more generic, at least in the terminology). So, thinking about the middlebox aspect is interesting. 

On which basis, a few questions:

1. On the 'directional property' (6.3) I see the reasoning clearly. The implication of this (to me) is that the ability to support receiver initiation as well as sender initiation is a must (in fact, a MUST). Is this true?

2. With a QoS background, we've tended to think in terms of a chain-of-trust model (in fact, a chain-of-AAA-interactions) model. Does the same thinking apply in the middlebox case, or something more complicated? This assumption has quite a big impact on the way an eventual protocol gets structured (it's one of our framework critical issues.)

3. Relatedly, I guess that using NSIS for this might commonly result in partial failures ("i've set things up this far but the rest needs to be done from the other end"). Again, thinking about semantics of acknowledgement/error messages was one of our open issues. Do you think that this sort of thing could be service specific (and hence opaque to NSIS) or does the protocol have to account for it somehow?

4. The multihomed network problem (6.5) is clearly a headache. It seems to me that we really need a  sort of ultra-lightweight path discovery message (icmp based?) which the sender can generate (maybe at receiver request), but which carries so little information that people will be happy-ish (maybe...) to let it through firewalls. But i don't know whether this is in the scope of NSIS to think about (it should be 'on-path' enough for most people...)

Cheers,

Robert

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: 24 June 2002 20:18
> To: [email-masked]
> Subject: [NSIS] draft on middlebox communication and NSIS
> 
> 

Marcus

---

From: Melinda Shore <[email-masked]>
Date: Tue, 25 Jun 2002 12:55:19 -0400

I'd like to take a shot at these, if I may.

>1. On the 'directional property' (6.3) I see the reasoning clearly. The implication of this (to me) is that the ability to support receiver initiation as well as sender initiation is a must (in fact…

Not necessarily - a sender-initiated "reservation" may include
rules to describe incoming packets.  It's probably best to think
of the problem in terms of who owns the policy in the firewall
and who's allowed to manipulate it (and there are some rather
difficult issues here with regard to firewalls outside the
sender's policy domain).  I tend to think of this use of signaling
as being responsive to individual endpoint's *application's* needs,
and not being useful for general firewall provisioning/configuration.

>2. With a QoS background, we've tended to think in terms of a chain-of-trust model (in fact, a chain-of-AAA-interactions) model. Does the same thinking apply in the middlebox case, or something more…

This is a huge problem, actually.  Aside from the lack of authentication
infrastructure that would allow arbitrary middleboxes to authenticate
to each other, there's an authorization problem, as well.  It is 
incorrect to assume that you can trust anybody who authenticates 
correctly (assuming that's possible in the first place).

>4. The multihomed network problem (6.5) is clearly a headache. It seems to me that we really need a  sort of ultra-lightweight path discovery message (icmp based?) which the sender can generate (may…

I would argue that moving a path discovery mechanism out of scope
(or at least out of the protocol) removes responsiveness to routing
and topology changes.  But aside from that, one of the tremendous
advantages to using an RSVP-like approach to talking to middleboxes
is that it allows correct operation in the face of the kind of minor
topological complexity that would stymie midcom.  For example, in
the path from here to there you've got a firewall and you've got a
NAT.  How do you know what address to present to the firewall in your
pinhole request?

Melinda

---

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 26 Jun 2002 13:55:50 +0100

Hi Melinda,

Please excuse my verbose answer.

> From: Melinda Shore [mailto:[email-masked]]

You're welcome. Thanks for the bullets.

> >1. On the 'directional property' (6.3) I see the reasoning 
> clearly. The implication of this (to me) is that the ability 
> to support receiver initiation as well as sender initiation 
> is a must (in fact, a MUST). Is this true?
> 

I used the term 'receiver initiated' to mean 'receiver of data packets sets up the reservation' (this is the way I think it's used in the NSIS requirements draft). So, when you say 'sender-initiated reservation ... incoming packets' I think we must be describing the same requirement. (And we have to think of the incoming and outgoing flows as basically logically distinct, because of asymmetric routing reasons.)

The reason I raise the question is that there is an open issue in the requirements draft about whether we can restrict NSIS to thinking about the sender initiated case (i.e. only support signalling for reservations about outgoing packets), since you can sometimes build a very lightweight protocol under this assumption. However, it appears that it can't cover all the bases (especially this one).

> 
> >2. With a QoS background, we've tended to think in terms of 
> a chain-of-trust model (in fact, a chain-of-AAA-interactions) 
> model. Does the same thinking apply in the middlebox case, or 
> something more complicated? This assumption has quite a big 
> impact on the way an eventual protocol gets structured (it's 
> one of our framework critical issues.)
> 

Yep, it's clear that this is a hard issue. But even apart from the solution, I'm still struggling to work out what the gross operational requirements are in the multi-'domain' case (it's one of our prime framework issues, section 3.3.3 of our latest framework draft). To be specific, consider the following example:

host --[1]-- nsis entity A --[2]-- nsis entity B --> rest of world

([1] and [2] are logical associations - we call them 'peer sessions' - between peer NSIS entities, which might extend over multiple IP hops.)

We've found it would be nice to assume that the AAA (at least, the first two As) aspects of [1] are independent of the AAA aspects of [2], and so host and NSIS B don't have any mutual authentication or authorisation (if they do, they set up a direct peer session). But we don't know if this is reasonable, because it obviously depends on the resource type being signalled for.

Actually, there is a good case for saying that AAA aspects are out of NSIS scope because they're all resource specific (and opaque to us). But, authentication is related to key management, and we'd like NSIS to be able to do something sensible for its users in this area, and authorisation models seem to affect state storage requirements where authorisation at one node is contingent on authorisation at another node (before or after it in the signalling chain). So, it seems we at least need to be thinking about it at some level.

> 
> >4. The multihomed network problem (6.5) is clearly a 
> headache. It seems to me that we really need a  sort of 
> ultra-lightweight path discovery message (icmp based?) which 
> the sender can generate (maybe at receiver request), but 
> which carries so little information that people will be 
> happy-ish (maybe...) to let it through firewalls. But i don't 
> know whether this is in the scope of NSIS to think about (it 
> should be 'on-path' enough for most people...)
> 

It's clear that we need technologies for path discovery for precisely this reason. I'm not sure how many technologies there should be. NSIS will (I hope) develop a general RSVP-like mechanism; I'm wondering if it also needs a special lightweight variant which firewall administrators are happy about being transparent to.

Your question about NAT traversal is a good one, which we also tried to consider explicitly in our latest framework. In the simple host-NAT-firewall case, we would have the NAT as a nearly-transparent 'NSIS forwarder' that re-wrote the flow definition part of the message. By the firewall saw the signalling, the pinhole request in the opaque part of the message would refer to the modified (and locally valid) flow definition. But I haven't looked at all the other cases (e.g. in your TIST draft), and in particular I'm not sure whether NSIS should be able to carry actual mapping table entries (it's not an NSIS requirement at the moment). There are too many protocol specific NAT traversal proposals for me to keep up with ...

> Melinda
Robert H.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 26 Jun 2002 11:46:48 -0400

>The reason I raise the question is that there is an open issue in the requirements draft about whether we can restrict NSIS to thinking about the sender initiated case (i.e. only support signalling…

I would tend to want to do that for this particular application,
anyway, because 1) in the cases which make firewalls and NATs
difficult in the first place (VoIP, for example) the receiver won't 
have sufficient information (i.e. addresses and port numbers) to
request the reservation until the sender tells him, anyway, and
2) there may be policy reasons to have the person initiating
the request "closer" to the administrative domain of the sender.
That last bit is muddy, granted, and needs a lot more work in 
general - it's related to the security difficulties that we'll
surely be grappling with.

>We've found it would be nice to assume that the AAA (at least, the first two As) aspects of [1] are independent of the AAA aspects of [2], and so host and NSIS B don't have any mutual authentication…

It's a little messier than that, actually - one of the benefits
of talking to middleboxes like this is that you don't need to know
where they are in advance.  That is to say, you don't need an
existing relationship with them.  The difficulty is that for 
practical purposes there's no good way in the internet *today*
to have arbitrary entities be authenticated to each other (TLS
works because a limited number of servers buy certs from more-or-
less trusted certificate agencies - imagine every middlebox doing
that).  But here's the real question - even if you could authenticate
someone you'd never known existed, on what basis do you authorize 
them to, say, open a hole in your firewall?

>It's clear that we need technologies for path discovery for precisely this reason. I'm not sure how many technologies there should be. NSIS will (I hope) develop a general RSVP-like mechanism; I'm w…

The problem is how you intend to use the information.  Aside from
the fact that the folks who run big networks don't *want* you to know
where their firewalls are, I've been looking at some of the arguments
for middlebox discovery and haven't found anything particularly
compelling.  Actually, that's not quite right - what I have found is
a compelling argument for not doing it.  It's like programming -
if you do some work to find out whether or not you can do something
and if you can then you try to do it, you create potential race
conditions.  If you just go ahead and do it and check the results
you'll know whether or not you succeeded, you saved yourself the overhead
of running checks ahead of time, and you avoid race conditions.

I've gotten religion about this, and so you'll have to forgive me.  If
you do middlebox discovery it suggests that you intend to do something
with the information that you collect.  There are multiple problems
with doing so, including that discovery only gives you a picture of
the network at the time that you did the discovery, and yet one of
the things we like (don't we?) about IP is that routing is adaptive
to changes in network state on a per-packet basis.  By establishing
explicit connections to middleboxes and wiring state into middleboxes
we're violating two fundamental IP design principles, one of them
major and the other somewhat lesser.  The major one is that of fate-
sharing, which is part of what makes (or used to make) applications
running over IP so robust.  The lesser one is layering, although
I feel pretty strongly that layer violations lead to network 
topology problems and perhaps isn't so lesser after all.

I would tread quite lightly where discovery is concerned.

Melinda