Subject: discovery & authorisation requirements (was: RE: [NSIS] draft on middlebox communication and NSIS)

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 27 Jun 2002 08:47:48 +0100

Hi Melinda,

On "discovery": I think there's a small point and a bigger point.

Small point (?): I don't want to imply too much by the term "discovery". So far as I'm concerned, the RSVP PATH message is a discovery mechanism (in the sense that it's the mechanism by which an RSVP capable node discovers its upstream neighbour to send RESV messages to), and I assume you're happy with that. It still seems the most general way for a receiver to find the ingress node for a flow, but some very stripped-down PATH-equivalent could be used for that (how many firewalls will happily pass a PATH message I wonder). I'm just not sure how many alternatives NSIS should try to investigate. I'm certainly not interested in developing a general purpose "let's go out and find all the middleboxes in the Internet" solution, and I don't think anyone else is proposing that either.

Bigger point: it would clearly be nice if we could make 'what NSIS does' adaptive to network changes to the same extent that packet routing is. But NSIS is all about creating flow state or something (e.g. per-some-class state) derived from it. (If NSIS didn't modify the network state along the path, we could all pretty well stop now.) The ideal (for some people) seems to be that all that state should be soft, but as soon as authentication and message protection (let alone service negotiation and authorisation) are involved I guess this is going to be tricky. If your neighbour middlebox changes, do you really want to be kept ignorant of the fact? Just finding out automatically and reacting seems the best one can aim for; maybe I'm over pessimistic.

Your questions about how on earth authorisation will take place are of course reasonable. But so far as I can tell, the mechanisms by which this will happen are highly resource-type specific and so defining them is out of scope of NSIS (we suggested this in our latest framework draft anyway); I think the best we can do is see if there are particular types of operations which don't need authorisation (e.g. if you can prove you're the same person who opened a pinhole, you probably don't need to be re-authorised to close it??). I don't know if this view is generally held (it's not compatible with a strict reading of the latest set of requirements).

Robert H.

> -----Original Message-----
> From: Melinda Shore [mailto:[email-masked]]
> Sent: 26 June 2002 16:47
> To: Hancock, Robert; [email-masked]
> Subject: RE: [NSIS] draft on middlebox communication and NSIS
> 
> 
> At 01:55 PM 6/26/02 +0100, Hancock, Robert wrote:
> >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).
> 
> 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 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.
> 
> 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 wondering if it also needs a special 
> lightweight variant which firewall administrators are happy 
> about being transparent to.
> 
> 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
>

---

From: Melinda Shore <[email-masked]>
Date: Thu, 27 Jun 2002 10:08:42 -0400

At 08:47 AM 6/27/02 +0100, Hancock, Robert wrote:
>I'm just not sure how many alternatives NSIS should try to investigate. I'm certainly not interested in developing a general purpose "let's go out and find all the middleboxes in the Internet" solution, and I don't think anyone else is proposing that either.

No, certainly not - aside from the topology problems I've
discussed, network operators typically do not want to make
known the location of their firewalls.

>Bigger point: it would clearly be nice if we could make 'what NSIS does' adaptive to network changes to the same extent that packet routing is. 

What I think I'm getting at here is the ability to allow applications
to adapt to changes in network state, if needed.  Consider two very
different cases - firewalls and NATs.  The sender periodically sends
out idempotent Path messages that possibly are either signed or have 
some other sort of authentication mechanism.  A routing change forces 
packets to traverse a new middlebox (i.e. one not on the original path).  
In the firewall case adaptation is pretty straightforward - the
firewall authenticates the message (introducing new state - I would never
suggest simply moving the state [although there are some interesting
group keying possibilities evolving as that work progresses]) and
opens the new pinhole (or not).  In the NAT case in addition to 
adding new authentication/security state, the contents of the Resv
message that are returned to the sender have changed.  That is to
say, the address at which the sender is seen by the receiver has
changed.  With that piece of information here is an opportunity for
the application to adapt (although I think it highly unlikely that
this kind of capability will creep into, say VoIP protocols).  I
would never suggest that it's the responsibility of the signaling
system to do anything but carry the new address back to the sender.

Melinda

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