Re: [radext] Last call comments on draft-ietf-radext-fragmentation-02

["Jim Schaad" <[e-mail]>]

 

 

From: Alejandro Perez Mendez [mailto:[e-mail]] 
Sent: Friday, February 07, 2014 12:45 AM
To: Jim Schaad; [e-mail]
Cc: [e-mail]
Subject: Re: Last call comments on draft-ietf-radext-fragmentation-02

 

Hi Jim,

thanks for the valuable comments. See my responses inline:

El 07/02/14 01:42, Jim Schaad escribió:

In general, yes I believe this document is in good shape and ready to go
forward.  There are a couple of small things that need to 
 
 
1.  !!! Pet Peeve !!! - I would request that the authors please review the
use of 2119 language.  There are places where, IMHO, it is used incorrectly.
Examples are:

 

 
       (section 2) Instead, the CoA client MUST send a CoA-Request packet
containing session identification attributes, along with Service-Type =
Additional-Authorization, and a State attribute.      ---- I don't think
this is part of the fragmentation protocol


Take into account that Service-Type = Additional-Authorization is a new
value defined in this document.

 

[JLS] Then I have a confusion about why this needs to be done.  It says that
there is no need to fragment CoA packets, so why is there a need to do this?
This may be due the fact that I don’t really understand what CoA is doing –
so I am willing to say this is reader misunderstanding and you can ignore
it.





 
5. Next paragraph - does it really need to be globally unique?  Is it
sufficient to be unique to either the server or the server/NAS pair?  The
problem with the phrase "globally and temporally unique" is that says to me
that it can never be re-used ever in the history of the world by anybody and
I don't think that is what is implied here.


Note that it says globally and temporally unique. That "temporally" addition
would allow others to use the same value after/before a reasonable amount of
time.
Anyway, I think it would be sufficient to be temporally unique to the
server, as it is the one using it to recognise the conversation. The NAS
just copies the value into the next Access-Request packet, without further
processing.

To avoid confusion, I think it could be rephrased as: 

We only note that it MUST be temporally unique to the server.

 

[JLS] Yes – I think this is probably a sufficient degree of uniqueness.

 
 

 
7. Section 7.1 - I may have a slight misunderstanding here (and it may not
be worth changing the document for this in any case).  However, I believe
that a proxy can remove all previous proxy-state information and just insert
its own into a packet.  Thus it is possible that the server does not know
how many bytes to allow for proxy state as not all of the attributes will be
sent to the server.  (I just found that this is discussed in step #2 of this
section, which makes me less inclined to include in the general discussion
but still unsure.)


Proxies can do anything they want, even completely change the whole packet
removing the existing attributes and inserting new ones. From this
assumption, the NAS and the AS can only wish proxies will behave according
to some conventions. Anyway, this discovery mechanism is a best effort.
That's why step #2 specifies to artificially increase the amount of free
space.

[JLS] – I can easily live with no change for this.

 
 
 
 
11.  Did I miss where you defined the T bit - or did you?


Page 7, first paragraph says:

We address this issue
   by defining a new field in the Reserved field of the "Long Extended
   Type" attribute format.  This field is one bit in size, and is called
   "T" for Truncation. 

That is, the T flag belongs to a different specification: RFC 6929. Perhaps
we should add a reference. s/attribute format/attribute format [RFC6929]/

[JLS]  The following text is in your document

We address this issue

   by defining a new field in the Reserved field of the "Long Extended

   Type" attribute format.  This field is one bit in size, and is called

   "T" for Truncation.


This says you need to have a section to define it and mark your document as
updating RFC 6929.

 
 
12.  This may just be me, but I have a problem with the terms
"pre-authorization" and "post-authorization".   My issue with the terms is
that there are three cases where I see things happening:
 
       a) Before doing the authentication (NAS->server)
       b) Post doing the authentication (NAS->Server)
       c) "post" doing the authentication (Server->NAS as part of the
access-accept process).
 
       However the document currently says that c is post-authorization but
b is not covered in section 12.


Personally, I don't see your case b) as a plausible case (I may be wrong).
Note that the NAS does not distinguish "after authentication" until it
receives the Access-Accept packet, and that would be c) already.

If your concern is more related to the naming itself, maybe these
phases/steps should be renamed to "pre-authentication" and
"post-authentication". I have thought on changing them sometimes in the
past.



[JLS] This is something that Plasma is looking at for a standard model.  We
are going to be using ABFAB and doing the following steps:

1.        Do a pre-authentication by sending a policy to the server  as part
of the initial Access-Request step

2.       Do a post-authentication by sending a SAML request to the server to
get various attributes that we need in order to do the policy evaluation to
grant access to a resource.

 

By doing this as two operations rather than one, we can restrict the amount
of items that we ask for, i.e. by not asking for things that are not
applicable to the person that is authorized.  This increases the privacy and
reduces the chances that the server would see us as trying to just get tons
of attributes.

 

We are looking at doing this by sending another Access-Request with a state
from the previous Access-Request in order to tie together the two sessions.
Since this dialog would not need to do an authentication (tied from the
previous dialog) it still is a post-authentication dialog, but is NAS
initiated again.





 
 
13.  Should the Access-Request (ID=181) 
 
14.  In the last paragraph on page 15, you are putting in a state attribute
where one did not exist in the original request.  It is not clear to me why
this is happening just because this is the fragmentation protocol.  It would
seem to me that this is something that should be done in general for all
access-accept messages, whether or not it is going to be fragmented.


I guess you mean page 14. It is stated that "The AS includes an State
   attribute to allow the client to send additional authorization data."

We added this text because we wanted the AS to provide the NAS with the
means to continue with the authorization exchange (e.g. further requests).
Now that you brought up, I think that it  should probably be out of the
fragmentation protocol. Perhaps it should be a recommendation for ASs to
include a State attribute on all their Access-Accept, as a way to allow NASs
to continue with the conversation.



[JLS] No I meant the last pargraph on page 15.  I was looking at the text

 

The AS includes an State

   attribute to allow the client to send additional authorization data.

 

This is where the final chunk is being constructed.

 

However – yes I would like a recommendation that a state attribute be
included in all Access-Accept messages where “post-authorization” in terms
of what I laid out above is going to be possible.





 
 
15.  Section 5 - I don't know if there is a reason to discuss packing based
on the re-ordering of attributes which have disparate types in order to pack
the chunk tighter.


I'm not sure that would be worthy. That would require to execute an
optimization algorithm just to gain some bytes.

[JLS] – No problems – I would have stated it in terms of – you can do this
but it is not worth the effort.

 
 
16. Section 8.1 - It might be worthwhile to repeat that implementations
SHOULD send this attribute in the an Access-Request with the value of
Fragmentation-Supported if fragmentation is not going to happen.


I guess we could provide a one-line explanation of each value for "code"
field.

[JLS] No that is not what I was asking for.  I was looking for a restatement
of the following text from section 4.2

 

Client supporting this specification MUST include a Frag-Status =

   Fragmentation-Supported attribute in the first Access-Request sent to

   the server, in order to indicate they would accept fragmented data

   from the sever.  This is not required if pre-authorization process

   was carried out, as it is implicit.

 


Thanks and best regards,
Alejandro