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

[Berg Stefan ICM Bocholt (stefan.berg]

Hi Jari!
Thank you, for your comments! See inline...

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

OK. I agree that EAP, because of its characteristics and features, is not
"the best" choice for exchanging this kind of information. But I consider
EAP as one possible alternative, which has quite good chances to prevail,
because it is already wide spread used in many exisiting implemetations. Of
course other/new protocols may be better suited. As Bernard already noted,
we also have to look at the current IEEE link layer activities, especially
the WIEN SG.

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

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

You're right! We have to think this over... 

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

I see the point, but with our test implementation we haven't reached the
limitations yet. Of course for larger installations the limitations have to
be taken into consideration.

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

As Bernard proposed a notification for the client and then an EAP-failure
would be good.

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

OK. Of course you're right.

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

We just tried to use a standard packet header, so that the netinfo-packet is
suitable for various protocols.

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

Our intention was to verify, whether the proposed solution is working or
not, and to start a discussion, whether additional information is useful and
how it could be provided.

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

OK! Thank you! Will be modified...

Regards,
Stefan