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

From: Marcus Brunner <[email-masked]>
Date: Tue, 02 Jul 2002 16:14:41 +0200

--On Donnerstag, 27. Juni 2002 08:47 +0100 "Hancock, Robert" 
<[email-masked]> wrote:

[...]
> 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.

Isn't this a general problem for security related issues in NSIS. Where 
changing routes means changing security associations.

Marcus

> 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
>>

--------------------------------------
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, 2 Jul 2002 16:11:39 +0100

Hi Marcus,

I think I probably agree with you. I was just responding to the penultimate paragraph in Melinda's email (at the end); see also her response. Essentially the question seems to be, how hard should we work to minimise explicit routing dependencies (especially in security associations), and how much should we just accept it. (You might be able to remove some of this state information e.g. with heavier use of public key methods and certification, but I'm not sure that the end result would be preferable to something which accepted a more explicit negotiated security association.)

Robert H.

> From: Marcus Brunner [mailto:[email-masked]]
> Sent: 02 July 2002 15:15
> To: Hancock, Robert; 'Melinda Shore'; [email-masked]
> Subject: Re: discovery & authorisation requirements (was: RE: [NSIS]
> draft on middlebox communication and NSIS)
> 
> 
> 
> 
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.