eap Mailing List: comments on draft-groeting-eap-netselection-results-00.txt

[Jari Arkko (jari.arkko]

Wolfgang & co,

Thank you for submitting this draft! I think its a very
useful approach that you have run experiments using a
real implementation and provided us with some feedback
based on that. This is very much needed.

Here are a few comments from my first reading:

Technical:

>  EAP is a generic container protocol that can - in theory - carry any
>  information desired by the network (as long as both sides of the
>  information exchange understand the information that they are
>  receiving).  It is an obvious choice for Layer 2 information exchange
>  about network capabilities since it is highly likely that EAP will be
>  implemented in both, the end host and the network.  However, when EAP

I disagree about EAP being an obvious choice for this purpose.
I think we have consensus that we can use it in a very
limited fashion (a la Farid's draft), but EAP's lack of
multicast support, request-response model, lack of fragmentation
support, and small MTU size makes it a cumbersome protocol
for a general purpose information exchange. But you already
note much of this later in the text. Maybe s/an obvious choice/one
possible alternative/.

>  is used in this fashion (i.e., beyond its original intention) it is
>  important to note that there are possible impacts on security,
>  scalability and the EAP state machine.

Indeed.

>   Importance: Mandatory for authentication purpose
>   When discovered: Pre-authentication
>   How dynamic: Inter-attach

This type of classification seems quite useful. I'll
adopt some of the concept to draft-ietf-eap-netsel-problem
in fact, if you don't mind...

>  The AN will receive information from the home network about what the
>  user is authorized to access and for how long.  If this information
>  can be transferred to the MT then it can be used to make informed
>  decisions e.g.  about interface selection - there is no point
>  choosing to use an interface if it is about to become idle because
>  the time for which it is authorized is nearly finished.  It would
>  also be useful for feedback to the user.  As this information might
>  belong to a particular user, it needs further investigation on how to
>  secure such kind of information.  A plain authorization information
>  advertisement seems rather difficult to realize.
>
>     Importance: Optional
>     When discovered: Pre-authentication
>     How dynamic: Duration of Session
>
>  The functionality required to obtain this information is quite
>  complex and does not yet exist so this information is considered to
>  be optional at the moment.

Indeed. In fact, without a more specific example on what such
authorization would tell us, I'm not sure we even need to
consider this part at all. All that I can think of is things
like "Am I going to get a public IP address?" or "Do I get
access from here or is it necessary to do a manual web-page
login first?". Such questions will be answered later by a
trial-and-error process, but it would be much better if the
mobile node could choose the optimal access network
from the start.

> 2.2.5  Privacy Policy

This is interesting, though maybe not so critical. The
location of the user will be roughly known by his IP
address in any case. And I suspect that there are
legal interception & goverment regulations that
dictate that the networks have to hand over any
information in any case, if requested. So it isn't
clear to me what value an advertisement of a privacy
policy has.

>2.2.6  Middlebox Devices

This would be very useful!

>    In [I-D.adrangi-eap-network-discovery] the following syntax is
>    proposed: network-info = attribute "=" value.  for just transmitting
>    the names of the mediating networks, this syntax is useful.  When
>    offering e.g.  six attributes about three mediating networks there
>    occurs a problem with the space available in the EAP packet.  A
>    solution to that problem is to send the network information in a
>    defined order, seperated with a defined delimiter.  Figure 2 is a
>    possible way to transmit information about: the name of the mediating
>    network, the cost of the mediating network, roaming agreements,
>    quality of service , middlebox information and authorisation
>    information (in this exemplary for three mediating networks):
>
>            _______________________
>           |       |       |       |
>           |  MN1  |  MN2  |  MN3  |          MN: Mediating Network
>           |       |       |       |
>           |-------|-------|-------|
>           |       |       |       |
>           |  C1   |  C2   |  C3   |          C:  Cost
>           |       |       |       |
>           |-------|-------|-------|
>           |       |       |       |
>           |  RA1  |  RA2  |  RA3  |          RA: Roaming Agreements
>           |       |       |       |
>           |-------|-------|-------|
>           |       |       |       |
>           |  QS1  |  QS2  |  QS3  |          QS: Quality of Service
>           |       |       |       |
>           |-------|-------|-------|
>           |       |       |       |
>           |  MI1  |  MI2  |  MI3  |          MI: Middlebox Information
>           |       |       |       |
>           |-------|-------|-------|
>           |       |       |       |
>           |  AI1  |  AI2  |  AI3  |          AI: Authorisation Information
>           |       |       |       |
>           |-------|-------|-------|
>           |       |       |       |
>           |  PP1  |  PP2  |  PP3  |          PP: Privacy Policy
>           |       |       |       |
>            -----------------------
>
>                 Figure 2: Matrix for Network Information
>
>    Converted into a string this data looks like (used "," as delimeter
>    between attributes and ";" as delimeter between values):
>    network-information=MN1;MN2;MN3,Cost1;Cost2;Cost3,
>    RA1;RA2;RA3,QS1;QS2;QS3,MI1;MI2;MI3,AI1;AI2;AI3,PP1;PP2;PP3

Please don't use the EAP Identity Request packets for
a transmission of all this data. Farid's draft very clearly
states that you can transfer intermediate network names
(roaming information), but nothing else. As you point out
above, the space runs out very fast.

>    One thing missing in this behaviour model is the reaction on an
>    Identity-Response which arrives the second time - without having
>    changed anything in username attribute.  For this reason a counter
>    has to be inserted into FreeRADIUS-code which makes it possible to
>    check for packets who are arriving more than one time.  As proposed
>    in [I-D.adrangi-eap-network-discovery] the AAA-Server has to handle
>    these packets based on the local routing policy.  In fact the
>    AAA-Server SHOULD discard these packets and send an EAP Failure
>    packet which stops the authentication process.

This seems like a useful thing to add to Farid's draft.
If there simply is no routing entry for the requested
network, no decoration, and you have already sent one
EAP identity request with the mediating network info --
all you can do is fail.

>  At supplicant side there is also one point where it makes most sense
>  to implement a query when to send a decorated-nai.  This is on every
>  incoming Identity-Request. For example all incoming
>  Identity-Requests could be checked for their size, and then be
>  interpreted or not.

I'm not sure I understand the text above. Can you clarify?
In any case, as rfc2486bis notes, decorated NAIs shall not
be used unless there is explicit knowledge (config or
via discovery) that the bang syntax can be used.

>  If it decides not to continue with authenticating process, the
>  supplicant SHOULD send an EAP logoff packet.  Else an
>  Identity-Response has to be sent, which includes a decorated-nai as
>  username.  Part of this decorated-nai is the chosen mediating
>  network.

Note that the decorations must always be optional, even if
there was an advertisement for mediating networks. Otherwise
current clients will fail to connect. So jari [at] arkko.com should
work without decorations, as long as there is a routing entry
in the AAA chain for arkko.com.

>           1 byte       2 bytes      1 byte
>          |------- |----------------|------- |
>          |  Type  |   Length       |   NoM  |
>          |--------|----------------|--------|
>          |  Data                            |
>          |----------------------------------|
>
>       Figure 4: Design of a Netinfo-Packet

Can you clarify which protocol layer you intend
to carry this in?

> In fact, most administrators of WLANs do not change
> the default SSID (see for example [Pri04] for a study about WLAN
> usage in London where approximately 40% of the access points are
> running their default SSID.) Such an approach makes the phone book
> (see [RFC3017]) approach (as an out-of-band mechanism to associate a
> particular service to an identifier) difficult to deploy.

This is an interesting observation! I'll include this
too in draft-ietf-eap-netsel-problem-01...

>  As a summary, to provide a short-term solution the authors suggest to
>  provide a mechanism to exchange information about the offered and the
>  desired service between the end host and the access network.
>  Subsequently, this information has to be repeated both in the EAP
>  method and the AAA infrastructure to give the user and the home
>  network the ability to detect fraud.  This proposal has not been
>  verified by the current implementation and hence needs further
>  assessment.

I agree with this general approach. (But I'd like to keep the
information down to the very basic data, i.e., mediating networks,
and not include e.g. QoS.)

Editorial:

- s/that the algorithmus comes to a decision if to
  proceed authenticating/that the algorithm comes to
  decision on whether to proceed with the authentication/

- s/exemplary/example/

--Jari