Subject: RE: [NSIS] draft on middlebox communication and NSIS

From: Marcus Brunner <[email-masked]>
Date: Mon, 01 Jul 2002 18:13:40 +0200

Robert,

--On Dienstag, 25. Juni 2002 09:57 +0100 "Hancock, Robert" 
<[email-masked]> wrote:

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

Yes, thats why I did it.

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

Actually, it is difficult to say. The reasoning is not technically 
motivated. Additionally, I seams to be more a security problem in terms of 
who is authorized to receive the service. Since there might have happen a 
different (high-level) signaling already, the right credential migh already 
be available for signaling on NSIS.

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

I am not sure what exactly the chain of trust model implies, but fact is 
that nodes inside the FW are trusted more than those from outside (again 
non technical argument). And I think the chain is not possible. I would 
think more in 1-to-1. Where the NSIS agent on the firewall exactly trust 
one entity (the final one) not over a chain of trust.

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

I not sure whether partial setup is a feature for QoS signaling as well. 
Might be a more general concept then. One the other hand, it is definitly 
possible to regard it service-specific. There definitly are implications, 
but they hold also for NSIS signaling over firewalls (not for firewall 
traversal)

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

I don't think we should spent too much in  this direction.

Marcus
> 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
>>
>>
>> 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-f
> mwk-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

--------------------------------------
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: Marcus Brunner <[email-masked]>
Date: Mon, 01 Jul 2002 18:13:46 +0200

[..]
>>
>> At 09:57 AM 6/25/02 +0100, Hancock, Robert wrote:
>> > 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?
>>
>> 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.
>
> 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).

I think in the NSIS context, it is again a question of definition of sender 
initiated with respect to AAA. If it is only about the data packets we are 
still fine, if sender initiated also means the identity behind the data 
sender then we have a problem.

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

Actually, I more and more think we should deal with AA in an opaque way. As 
I see it with the middlebox case, the trust models muight be service, 
dependent and are different even for QoS depending on the scenario used.

Marcus

[...]

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 2 Jul 2002 16:24:01 +0100

Hi Marcus,

By 'authorisation' I mean only authorisation. If we knew the authorisation requirements we would then know some of the authentication ones, but probably not all; but I don't think there is any question (is there?) about authentication being a requirement for NSIS anyway.

The current requirements draft (5.8.2) says "The signaling protocol must provide means to authorize resource requests." As it stands, that's quite broad. The rest of the paragraph talks about interactions with policy servers and sending notifications that an authorisation has succeeded. It doesn't seem to be the same as my (1), anyway.

Cheers,

Robert H.

> Sent: 02 July 2002 14:06
> To: Hancock, Robert; [email-masked]
> Subject: RE: [NSIS] draft on middlebox communication and NSIS
> 
> 
> 
> 
> --On Dienstag, 2. Juli 2002 13:03 +0100 "Hancock, Robert" 
[stuff snipped out]
> 
> > Authorisation: Here, there seems to be a much wider range 
> of reasonable
> > opinions. 1) Everything about authorisation should be 
> opaque to NSIS. If
> > NSIS messages can be used to transport authorisation 
> information that's
> > all very well, but we aren't going to worry about making it easy; if
> > people need message flows (even on-path ones) that don't 
> fit with NSIS,
> > they'll need another protocol to carry them. 2) 
> Authorisation messages
> > are opaque to NSIS, but we'll try to make sure that we can 
> support the
> > most important scenarios that we can think of within a basic set of
> > message flows. 3) Authorisation messages are opaque to 
> NSIS, but we'll
> > assume that the message flows can be absolutely anything 
> and the protocol
> > will have to be flexible enough to support that (even if that means
> > multiple passes and so on). 4) NSIS has to have 
> well-defined interactions
> > with authorisation protocols.
> 
> Do you mean here authentication or authorization or both. For me 
> authentication tells an entity who the other party is, and 
> authorization is 
> a entity local decision on whether the action another party wants to 
> perform is allowed to.
> 
> So from an NSIS point of view I see different entities with a defined 
> identity and a mechanism to authenticate. The only part I see 
> prety static 
> is the local authorization, but probably it is not that simple.
> 
> 
> >
> > The accounting view seems to be compatible with the 
> requirements (just
> > checked the latest version). For authorisation, I guess you 
> would prefer
> > (1)? I'd like (2) but that means some verification work. 
> (3) would be
> > horrible. The requirements seem currently closer to (4), but I'm not
> > absolutely clear. Seems like a tricky choice.
> 
> Yes, I would like (1). I don't see something which implies 
> (4) in the req 
> draft. What makes you think (4) is implied?
> 
> Marcus
> 
> > Cheers,
> >
> > Robert H.
> >
> >
> > 
> 
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.