eap Mailing List: RE: Review of draft-adrangi-eap-network-discovery-00.txt

[Adrangi, Farid (farid.adrangi]

Hi Bernard,
Thanks so much for your review and comments.  Please see my responses
below.
BR,
Farid


> 
> This document is comprised of several major sections:
> 
> 1. Introduction (problem statement)
> 2. Specification of the ABNF
> 3. Delivery options
> 4. Security Considerations
> 
> Overall, it seems to me that the material in Section 1 could be
> slimmed down or eliminated entirely via reference to the EAP Network
> Selection problem statement document.  For example, one of 
> the figures in
> Section appears to be duplicated as Figure 3 in the problem statement
> draft, as is some of the discussion.
> 

The problem statement draft provides an overview of four problems:

1) Access Netowrk Discocery
2) Idenitifier Selection
3) Selection of roaming intermediaries
4) Payload routing

Here we are focusing only on the problem #3 as we did in the original
draft (published before the problem statement draft). I don't think it
would be a good idea to eliminate the section entirely via reference to
the problem statement draft .  We have already slimmed down the section
1 with the help of Jari - and as you noticed we used Figure 3 as per
Jari's suggestion.   I can go through it again, maybe we can make it
more concise -- please this section is pretty short. 

> The terminology section should define the terms "MN" and "HSN".
> 
Yes.  Good catch.  In the latest version, the intent was not to use
these terms.  But, I think I left a few in the document -- will fix...

> There are a number of issues with Section 2:
> 
> a. The CHAR, DIGIT and ALPHA terminals are not defined or referenced.

DIGIT, ALPHA, CHAR are defined in RFC 2234.  I noticed alphanum was
undefined when I ran it through the ABNF checker - I have fixed it in
the later version along with other things -- please also see my response
to Jari's mail.  Here are the moidified ABNF definitions:


   identity-request-data = displayable-string [ %d0 network-info ]
   displayable-string = *CHAR

   network-info = attribute "=" value

   attribute =  1*( ALPHA / "-" / "_" / DIGIT)

   value = 1*( %x01-FF ) ; any non-null UTF-8 char


----

   value = Realm [ ";" Realm ]

   Realm = *( domainlabel "." ) toplabel
   domainlabel    =  (ALPHA / DIGIT) *( ALPHA / DIGIT / "-" )
   toplabel         =  ALPHA * (ALPHA / DIGIT)


> b. Is "=" a legal character within value?

Currently it is, as it does not make the definition ambiguious.  Do you
have any concerns about it?

> c. Rather than referencing RFC 2486bis, a separate definition 
> of "Realm"
>    is used that differs from that in RFC 2486bis.  Since 
> there is already
>    a normative reference to RFC 2486bis, referencing the definition of
>    "Realm" in that document shouldn't be a big deal.
> 

I guess you are right!  We could do that :-)

> Section 3 includes discussion of AAA behavior, including normative
> language that appears to update RFC 3579 and RFC 2607.  It also
> contains suggestions for operator deployment.  Both of these
> considerations don't seem necessary to me in a document of this type,
> which should focus on defining the EAP extension.  Instead, 
> I'd suggest
> that Section 3 be limited to discussion of EAP issues.
> 

I see your point.  Most of AAA behavior discussion is done in describing
the option 3 -- therefore it is going to be hard to describe how the
option 3 would work without making any references to AAA.  I will try to
reword the text in option 3, and send it to you for review.  

> Section 4 notes that the network information is a hint.  This 
> implies that
> existing implementations will ignore the hint, presumably without
> affecting interoperability.  

That's true.

> It also implies that the peer needs to be
> robust against misleading information, but this section does not
> describe the potential attacks or how a peer can guard against them.

Does IEEE describe how a peer can guard against spoofed SSIDs? I guess
we could include some discussion on potential attacks and possibly how a
peer can guard against them if you think it is necessary even thought we
are saying the information should be used as a hint.  

> I'm not sure that the analogy to the SSID is a good one, unless it's
> being suggested that Channel Bindings be used to verify the network
> information after the fact.
> 
> Section 6, references
> 
> Assuming that discussion of AAA is eliminated in this document, then
> normative references ot RADIUS or Diameter should not be 
> needed.  The only
> normative references would then be to RFC 2234.

Ok
> by the way, have you
> checked the ABNF??), RFC 3748 and RFC 2486bis.

I am not sure what the question is here.

> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>