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

[Berg Stefan ICM Bocholt (stefan.berg]

Hi Bernard,

Thank you, for your comments! I just added some remarks inline...

Stefan

> Jari Arkko noted:
> 
> "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..."
> 
> Yes, the discussion so far in 802.11 WIEN does not appear to suggest 
> that EAP is the obvious choice either, particularly if the wider 
> problem statement is taken into account (service discovery and 
> selection).

We're looking for solutions that work in various environments with different
technologies. Of course service discovery and selection is best done at the
lower layers. As a result we're quite interested in what happens in 802.11
WIEN (maybe we should have made an reference in the document), but WIEN will
work on an IEEE 802.11 specific solution. The scope of 802.21 is much more
general, but certainly will not cover all possible technologies. In our view
EAP may not be "the best", but at least an alternative solution for service
discovery and selection at a higher layer and a good starting point for
further discussions.

> 
>  >  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.
> 
> Actually I think there may be impacts even when used as intended.
> 
>  > 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.
> 
> Given the limitations of the EAP MTU size, and the inherent 
> inefficiency of the described syntax, it's quite questionable whether 
> these kind of extensions make any sense.  And if they are really 
> needed (which I can believe), then this argues for going another route 
> from the start, such as delivering the information at the lower layer.
> 
> Given that a straw poll at the IEEE 802.11 WIEN group indicated strong 
> support for standardization within 802.11, I suspect that we'll have 
> discussions on lower layer alternatives taking place fairly soon.
> Given this, the argument for publishing the EAP Network Discovery 
> document rests on its general utility (providing hints for selection
> of the right NAI for the EAP-Response), rather than its 
> suitability as a substrate for further extensions.
> 
> >    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.
> 
> 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.

> 
> > Can you clarify which protocol layer you intend
> > to carry this in?
> 
> Please keep in mind that there is chartered work within 802.21 as well 
> as 802.1af on Network Discovery, as well as the discussion going on in 
> WIEN. So there are lots of place to put this :)

Right! We always tried to be as generic as possible, so the netinfo-packet
could also be used with other protocols.