Subject: [netext] FW: Adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration as WG document?

From: <[email-masked]>
Date: Thu, 26 Apr 2012 11:39:31 +0000

Hi Jouni,

<Without chair hat>
The I-D proposes new attributes to be carried in EAP signaling. I believe
it is not specific to any individual EAP method.
Hence it is applicable to multiple EAP methods that may be used for access
authentication.
References to EAP-AKA' should be mentioned as an example IMO.

Since the I-D proposes new attributes to be carried in EAP, I do not
believe it can be Informational. Hence the reason for the PS status
proposal.

</without chair hat>
-Raj

On 4/26/12 4:23 AM, "ext jouni korhonen" <[email-masked]> wrote:
>
>>
>>Hi,
>>
>>Few initial comments on the WG draft.
>>
>>o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 instead
>>  of RFC4187.
>>o Both RFC4187 and RFC 5448 are Informational, thus why this draft
>>  aims to Standards Track? IMHO it should also be Informational.
>>o Should the draft state it updates RFC5448?
>>
>>- Jouni
>>
>>
>>
>>On Apr 20, 2012, at 10:20 PM, <[email-masked]>
>><[email-masked]> wrote:
>>
>>> 
>>> Hello,
>>> 
>>> I have not heard any negative views on adopting this I-D.
>>> I do believe that this I-D provides a good solution to the problem of
>>> indicating APN choice (in 3GPP networks) or handover indication
>>>(general
>>> applicability) to the MAG via EAP signaling.
>>> 
>>> Hence it makes sense to adopt this I-D as a WG document and progress it
>>>as
>>> a Proposed Standard.
>>> 
>>> I believe APN selection and Handover indication attributes within EAP
>>> messages are useful. I am not yet convinced about the multiple APN
>>> connectivity attribute. Hence I would recommend publishing this I-D as
>>>a
>>> WG doc with the scope limited to these two attributes.
>>> 
>>> I-D Authors, please go ahead and publish the I-D as a Netext WG doc.
>>> 
>>> 
>>> -Raj
>>> 
>>> <Please note that I will be acting as the sole responsible chair w.r.t
>>> this I-D> 
>>> 
>>> On 4/2/12 3:15 PM, "Patil Basavaraj (Nokia-CIC/Dallas)"
>>> <[email-masked]> wrote:
>>> 
>>>> 
>>>> Hello,
>>>> 
>>>> At IETF83 the WG discussed the I-D :
>>>> draft-valmikam-eap-attributes-wifi-epc-integration (EAP Attributes
>>>> for WiFi - EPC Integration)
>>>> 
>>>> This I-D proposes the use of EAP attributes as a means of signaling to
>>>> the MAG by an MN the parameters such as:
>>>> 1. Choice of APN
>>>> 2. Handover indication
>>>> 3. Multiple APN connectivity
>>>> 
>>>> These attributes are relevant in the context of an MN connecting via a
>>>> WiFi network to the 3GPP evolved packet core (EPC).
>>>> 
>>>> The discussion in the WG favored using EAP attributes for parameters
>>>> (1) and (2) above. The multiple APN connectivity problem is harder to
>>>> solve. 
>>>> 
>>>> Question to the WG members:
>>>> Should we adopt I-D draft-valmikam-eap-attributes-wifi-epc-integration
>>>> as a Netext WG document with the intent of standardizing the following
>>>> two attributes only : (1) Choice of APN and (2) Handover indication,
>>>>to be
>>>> carried in EAP signaling at the time of network access authentication?
>>>> 
>>>> Please respond to the ML (or to me privately) if you favor the
>>>>adoption
>>>> of this I-D or are opposed to it.
>>>> 
>>>> Adopt I-D: draft-valmikam-eap-attributes-wifi-epc-integration:
>>>> 
>>>> Yes [  ]
>>>> 
>>>> No  [  ]
>>>> 
>>>> -Basavaraj
>>>> 
>>>> ----------------------------------------------------
>>>> 
>>>> Abstract
>>>> 
>>>>  With WiFi beginning to establishing itself as a trusted access
>>>>  network for service providers, it has become important to provide
>>>>  functions commonly available in 3G and 4G networks in WiFi access
>>>>  networks.  Such functions include Access Point Name (APN) Selection,
>>>>  multiple Packet Data Network (PDN) connections and seamless mobility
>>>>  between WiFi and 3G/4G networks.
>>>> 
>>>>  EAP/AKA (and EAP/AKA') is standardized by 3GPP as the access
>>>>  authentication protocol for trusted access networks.  This IETF
>>>>  specification is required for mobile devices to access the 3GPP
>>>>  Evolved Packet Core (EPC) networks.  This document defines a few new
>>>>  EAP attributes and procedures to provide the above-mentioned
>>>>  functions in trusted WiFi access networks.
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> netext mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/netext
>>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Apr 2012 09:48:59 -0500

Hi Basavaraj,

I think that Jouni is absolutely right.

This draft wishes basically to update RFC5448, it should be called
rfc5448bis (and of course informational). RFC5448 was developed in EAP
WG, now there is EAP Method Update (emu) WG.

It think this work belongs to emu, IMHO.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Thu, 26 Apr 2012 18:16:35 +0300

Resending.. it seems I managed to goof with my postings again ;)

- Jouni

> it is not specific to any individual EAP method.

This solution is specific to EAP-AKA/AKA' as it reads now. It does not
work on a random EAP-method.

> Hence it is applicable to multiple EAP methods that may be used for access

Only if that method is SIM/AKA/AKA'.

> believe it can be Informational. Hence the reason for the PS status

I disagree. Attributes in this draft are method specific. This also
implies the IANA considerations should point to a specific registry.

- Jouni

>>>> indicating APN choice (in 3GPP networks) or handover indication (general
>>>> connectivity attribute. Hence I would recommend publishing this I-D as a
>>>>> Please respond to the ML (or to me privately) if you favor the adoption

---

From: jouni korhonen <[email-masked]>
Date: Thu, 26 Apr 2012 18:40:51 +0300

> It think this work belongs to emu, IMHO.

I would say currently in IETF, Netext definitely has the
best knowledge on the problem space this draft tackles.

- Jouni

---

From: <[email-masked]>
Date: Thu, 26 Apr 2012 15:50:43 +0000

Inline:

>WG, now there is EAP Method Update (emu) WG.

<Authors, please correct me if I am wrong with the statement below:>
This I-D is not proposing an update to the EAP method itself. It is adding
an additional set of attributes to the EAP messages.
Since this is not an EAP method update, I do not believe we need to take
this to the EMU WG. Of course we will engage with the EMU WG to ensure
that experts review the I-D and are aware of it as it goes through the
process.

The I-D is specifically adding attributes that assist a MAG in determining
of the HO flag needs to be set or in determining which LMA to send the BU
to (based on the APN attribute). Hence it is very much PMIP6 and Netext WG
centric.

-Raj

>>>>>> Should we adopt I-D
>>>>>>draft-valmikam-eap-attributes-wifi-epc-integration

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 26 Apr 2012 09:44:45 -0700

The draft only defines EAP Attributes.
These attributes affect the PMIP6 functioning in trusted WiFi environment.

Treat this as EAP attributes for PMIP6, just as we have done Radius
Attributes for PMIP6, in Netext.

-Rajeev