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

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 2 Jul 2002 13:03:21 +0100

Hi Marcus,

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

I don't know whether to read anything into using the term 'AA' not 'AAA'. But maybe we need some guesses about the second two As to work out where the scope lies. (Background concern: we could easily end up saying 'everything is opaque', in which case NSIS is just 'any protocol on top of IP'.)

Accounting: Actually, I think this is easy. "Nodes may generate accounting records, but there's no reason for them to follow the signalling path, and so no reason to integrate their handling with NSIS. So far as NSIS is concerned, accounting might as well not exist."

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.

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.

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.

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 02 Jul 2002 15:06:09 +0200

--On Dienstag, 2. Juli 2002 13:03 +0100 "Hancock, Robert" 
<[email-masked]> wrote:

> Hi Marcus,
>
> [snip]
>> 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
>>
>
> I don't know whether to read anything into using the term 'AA' not 'AAA'.
> But maybe we need some guesses about the second two As to work out where
> the scope lies. (Background concern: we could easily end up saying
> 'everything is opaque', in which case NSIS is just 'any protocol on top
> of IP'.)
>

Yes, I know. Actually, I excluded Acounting.

> Accounting: Actually, I think this is easy. "Nodes may generate
> accounting records, but there's no reason for them to follow the
> signalling path, and so no reason to integrate their handling with NSIS.
> So far as NSIS is concerned, accounting might as well not exist."
>

You might account based on reservation not usage.

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

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