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

[Alejandro Perez Mendez <[e-mail]>]

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 1) Nevertheless, if a proxy supports this specification, it
> MAY re-assemble the data in order to either examine and/or modify it.  ---
> This is not  protocol statement it is a statement of why one might wish to
> do something.  If the proxy does not implement the spec, it does not have
> this capability.

Right.

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

> 	(section 3) An authorization exchange before authentication allows a
> RADIUS client to provide the RADIUS server with information that MAY modify
> how the authentication process will be performed (e.g. it MAY affect the
> selection of the EAP method).  --- This decision process is independent of
> the fragmentation protocol and thus is not appropriate 2119 language.

Right.

>
> 2.  !!! Pet Peeve !!! - I have run into people who believe that the
> capitalization of may, should, must do not matter when defining 2119
> language.  Personally I think they are idiots for this view, but they
> strongly believe it.  For this reason I have started including the sentence
> "When these words appear in lower case, they have their natural language
> meaning." As part of the 2119 boiler plate.  You might want to consider
> doing so.

I think it is a good idea.

>
> 3.  On page 9 (after figure 2) - It is not clear to me what you mean by
> Non-compliant servers.  Are these servers that do not implement this
> specification or are they servers that do not correctly implement the RADIUS
> specification.  (Simple way to make it clear would be to add a parenthetical
> after the first occurrence of the term   "non-compliant (i.e., servers not
> implementing fragmentation)"

Right, that term is confusing.

> 4. Same paragraph - suggest s/a particular Service-Type/a Service-Type other
> than Additional-Authorization/  (I am not sure that is a correct statement
> in terms of the actual value returned, but particular does not give me
> something to code to)

I agree with your suggestion.

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

>
> 6. Section 4.2 - Para #1 - The requirements on the Service-Type attribute,
> while understandable, appear to violate a previous statement that the order
> of the attributes not be changed (Section 3 para 3  The encoding process is
> a simple linear walk over the attributes to be encoded.  This walk preserves
> the order of the attributes, as required by [RFC2865].)  This should
> probably be explicitly called out as being ok.  (This may be done by a proxy
> rather than the server.)  - Maybe point to the discussion in section 7.2 as
> well, although there it says that the attributes can be re-ordered.
>
> After a second pass through the document (with jumps to other documents), I
> still find this somewhat confusing language here.  Something that might make
> things a bit clearer
> 	In section 3 para 3 - s/order of the attributes/order of attributes
> of the same type/

Yes. When I read your comment I first thought exactly that, that order
must be preserved between attributes of the same type. I was going to
suggest a similar rephrasing as you did.

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

>
> 8.  Section 7.4 - Service-Type = Additional-Authorization should be included
> in the server list.

Absolutely. I forgot to add it.

>
> 9. section 10 - !! Pet Peeve !! - A MAC is not a signature and should not be
> called one.

Right, my bad. It should say:

     It requires that all Access-Request packets associated with
    fragmentation are authenticated using the existing
    Message-Authenticator attribute.  This attribute  prevents forging
    and replay, to the limits of the existing security.


>
> 10.  References
> 	(Which of the documents do I need to understand to implement - as
> oppose to understand background reasoning)
> 	RFC 2866 should be informational
> 	RFC 3579 should be informational
> 	RFC 5080 should be informational
> 	(Yes I could list others here such as how to write IANA
> considerations which the author needs to know but not the reader).

That makes sense.

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


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

>
> 13.  Should the Access-Request (ID=181) be Frag-Status = More-Data-Pending ?

Yes, thanks.

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

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

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

>
>
> Spelling errors
>
> s/wand/and/
> s/eight (7)/seven (7)/
> s/how many space/how much space/
> s/MUST not/MUST NOT/
> s/before start forwarding/before starting to forward/
> s/could be a reasonable limits/could be a reasonable limit/  or  /could be
> reasonable limits/
>

Thanks and best regards,
Alejandro