Subject: RE: [NSIS] NSLP authorization work

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 5 Jul 2006 11:23:33 +0100

hi,

i think this is an interesting document. i have some comments
on it:

*) section 3.1: this assumes that GIST defines the NLSP object
space and AB flag settings. however, this hasn't been true 
since version -06 (over a year ago!); at the moment, AFAIK
no document creates or describes the NSLP object registry.
(Incidentally, this can be taken as a WGLC comment on all the
current NSLP specs.)

*) section 3.2.1: i think it could be made clearer that the
addresses which can be used as identifiers here are orthogonal 
to addressing associated with the signalling nodes or the
resources being requested. 

*) section 3.2.3/3.2.4: carrying address/port information here
raises a number of concerns with me.
- there is no discussion of NAT traversal issues.
- it isn't clear whether the addresses should relate to e2e 
  flows or GIST/NSLP peers
- are the addresses always meaningful - e.g. what is the correct
  'called party' address for a NATFW REA message?
[the last point is a reflection of the issue that basing the
authorisation model too closely on rfc3520 may not be ideal, since
the session concepts themselves are not that directly related.]

*) section 3.2.7: likewise, the 'resources' attribute seems to 
run the risk of partial duplication of information which is 
already being carried in another form in the main body of the
NSLP.

my main concerns are the last two. it seems that related information
is going to be carried in the 'main' NSLP objects and also in 
the AUTH_SESSION object, and it is up to the NSLP implementation
at either end to compare and match the two. However, it's quite
unclear how much freedom there should be in doing this. For
example, what does one do about MRI wildcarding, or if a flow
label is specified, or if the token bucket is given in a Qspec
but not a bandwidth, and so on.

I suspect the underlying problem here is that different authorisation
infrastructures use different formats to represent the resources
that are authorised, so some unpleasant interworking is going to
be required somewhere. But doing that in a partial way in the NSLP 
seems very awkward.

r.

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: 26 June 2006 08:22
> To: [email-masked]
> Subject: [NSIS] NSLP authorization work
> 
> 
> 
> Hi all,
> 
> Hannes, Martin and myself have pretty much finalized our 
> proposal to add
> an authorization object to the NSLP layer. We'd like to hear 
> comments on
> whether this would be as usefull to have as we see it. The 
> draft includes
> e.g., the structure and use of the authorization object and message
> processing rules for the QoS and NAT/FW NSLPs.
> 
> http://www.ietf.org/internet-drafts/draft-manner-nsis-nslp-auth-01.txt
> 
> Regards,
> Jukka
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 7 Jul 2006 15:08:42 +0300 (EEST)

Hi,
thanks for the comments. Some words below (mainly "acks).

Jukka

> (Incidentally, this can be taken as a WGLC comment on all the

Thanks. :)

> resources being requested. 

Right.

> the session concepts themselves are not that directly related.]

Good points. We need to be more specific and think about the NAT-cases. 
The NAT/FW message processing and use need still more work.

> already being carried in another form in the main body of the

Good point. We need to think more about how we could re-use the QSPEC in 
this, e.g., through similar flags that the QoS NSLP uses for the packet 
classifier (pointing to GIST information).

> be required somewhere. But doing that in a partial way in the NSLP 

Those are good points. We took RFC3520 as the baseline, but we clearly 
need to work more on the draft to integrate it better with the NSIS way of 
signaling, and GIST and the NSLPs.