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

From: <[email-masked]>
Date: Mon, 2 Apr 2012 20:15:29 +0000

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.

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 03 Apr 2012 13:17:19 -0700

Yes [X]

There is a need to provide the APN and Handover Indication from a MN.
The ID specifies EAP attributes which are used in the required EAP-AKA'
authentication procedure.

Thanks.

-Rajeev

On 4/2/12 1:15 PM, "[email-masked]" <[email-masked]>
wrote:

> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: <[email-masked]>
Date: Tue, 3 Apr 2012 20:21:52 +0000

Are these attributes (APN and HO indication) applicable to any EAP method?
Or these attributes specific to only EAP-AKA'?

-Raj

---

From: <[email-masked]>
Date: Fri, 20 Apr 2012 19:20:40 +0000

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>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 26 Apr 2012 12:23:13 +0300

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

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 26 Apr 2012 08:05:43 -0700

Hi Jouni,

Thanks for the input.

> o Since EAP-AKA' is mentioned, I'd rather reference to RFC5448 instead

I believe since the EAP attributes registry is the same, the same attributes
should also be applicable to EAP-SIM/AKA/AKA'.

>   aims to Standards Track? IMHO it should also be Informational.

I think the attribute definition should be PS, no?

> o Should the draft state it updates RFC5448?

I do not believe it needs to. I will consult Jari on this.

-Rajeev

---

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

Hi Rajeev,

> should also be applicable to EAP-SIM/AKA/AKA'.

The registry is the same, sure. What I mean, is that RFC5448 also needs
to be reference since it is specifically mentioned in the draft. Just
nitpicking..

> I think the attribute definition should be PS, no?

No.. furthermore, the IANA registry for EAP-SIM/AKA/AKA' attributes
is specification required, which means any publicly available document
fulfills the requirement for a specification. Even a vendor product
spec would suffice. Personally, I rather have an RFC than something else..

> I do not believe it needs to. I will consult Jari on this.

Ack.

- JOuni

---

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

Hi,

> to be reference since it is specifically mentioned in the draft. Just

No problem, will reference RFC5448.

> spec would suffice. Personally, I rather have an RFC than something else..

Agree we need an RFC to capture this so that PMIP6 can benefit in trusted
WiFi deployments. 

-Rajeev