Subject: [eap] comments on draft-groeting-eap-netselection-results-00.txt

From: Berg Stefan ICM Bocholt <[email-masked]>
Date: Wed, 21 Jul 2004 17:05:35 +0200

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 [email-masked] 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
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Clint Chaplin" <[email-masked]>
Date: Wed, 21 Jul 2004 13:14:35 -0700

802.21 is supposed to solve the heterogeneous network handoff problem.  As an example, handing off from a wire network to a wireless network (you just unplugged your ethernet cable to go to a conference room) or vice versa, or from 802.11 to 3GPP.

Clint (JOATMON) Chaplin
Wireless Security Advisor
Wireless Standards Lead

>>> Bernard Aboba <[email-masked]> 7/21/04 09:53:55 >>>
> The scope of 802.21 is much more general, but certainly will not cover
> all possible technologies.

As I understand it, the intent is for the 802.21 work to apply to a range
of IEEE 802 wireless technologies.  Are there other media of interest?
Which ones?

> Actually, I'd argue for a Notification so that the client can figure
> out what is going on, and *then* an EAP Failure.
>
> Good idea! I think, this really makes sense.

This will might help the user to figure out what is going on.  Or at least
there will be something in the log to help the admin.

________________________________________________________________________
This email has been scanned for computer viruses.