Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-00.txt

From: [email-masked]
Date: Mon, 23 Apr 2012 11:23:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF.

	Title           : EAP Attributes for WiFi - EPC Integration
	Author(s)       : Ravi Valmikam
                          Rajeev Koodli
	Filename        : draft-ietf-netext-wifi-epc-eap-attributes-00.txt
	Pages           : 12
	Date            : 2012-04-23

   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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attributes-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-netext-wifi-epc-eap-attributes-00.txt

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Apr 2012 10:40:05 -0500

Hi Basavaraj, chairs,

I read this document and have some questions on it:

The draft is on defining 4 new EAP attributes and how to use them.

PMIPv6 relevance is very tangential,

 the document mentions PMIPv6 as one possible deployment choice in
Section 3.2 and that's all.

If you look at the call flow in Fig.1 there is no PMIPv6 at all.

The main purpose of this document seems to be to define four new EAP
attributes to be sent by the Mobile Node in 802.1X based
authentication exchanges over Wi-Fi links.

All these bring a lot of questions to one's mind:

1. Given that the draft wants to define NEW EAP attributes to be sent by MN,

 it is clearly extending MN.

This seems to be so obvious.

So the question is: can Netext work on such documents? The charter
clearly states that proxy mobility is based on network proxying the MN
so that we don't change MN?

Is this acceptable to the chairs?

Is this acceptable to WG?

Is this acceptable to IESG? I have cc'ed to Brian.

2. As I said above, the draft's main concern is MN authentication on
Wi-Fi links. As we all know, PMIPv6 is based on point-to-point links
and Wi-Fi link is a shared link.
Does this raise any concerns to you?

3. This one is procedural. What about the charter? The current charter
talks about Localized Routing, Bulk Refresh and LMA Redirection and
logical interface. I could not see defining new EAP attributes in the
charter?

Kind regards,

Behcet

PS. I wanted to bring to the attention the concerns I personally have.
No offense to anyone, please.

On Mon, Apr 23, 2012 at 1:23 PM,  <[email-masked]> wrote:
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: <[email-masked]>
Date: Wed, 25 Apr 2012 20:01:45 +0000

Response inline:

>Hi Basavaraj, chairs,

Please note that I am the sole chair responsible for this I-D (as
mentioned in a previous email as well to the list).

>PMIPv6 relevance is very tangential,

It is very much relevant. The use case has been presented quite clearly.
Given the lack of MN-MAG signaling at L3, the MN/UE cannot provide
indications such as Choice of APN (relevant in the 3GP context) or HO
indication to a MAG. By adding these attributes to EAP signaling an MN can
accomplish this task. The MN needs to authenticate with the access network
to which it attaches and this information can be signaled to the AN/MAG at
the time of attachment.

>Section 3.2 and that's all.

The I-D can elaborate further on how it ties in with PMIP6 for further
clarification if needed.

>If you look at the call flow in Fig.1 there is no PMIPv6 at all.

Right. That is because the APN choice and HO indication happens prior to
PMIP6 signaling (BU/BA). This information is used subsequently by
MAG<->LMA signaling which can be shown in the figure if that helps.

>This seems to be so obvious.

Yes. That is well understood.

>so that we don't change MN?

We are extending EAP signaling with the attributes. This does not mean
that we are creating a new MN-MAG signaling protocol which is out of scope
of this WG. You are misinterpreting what is intended by the statement "No
changes to the MN w.r.t PMIP6".

>Is this acceptable to the chairs?

Yes. 

>Is this acceptable to WG?

Consensus call was issued previously with no negative feedback.

>Is this acceptable to IESG? I have cc'ed to Brian.

Good. 

>Does this raise any concerns to you?

No. 

>logical interface. I could not see defining new EAP attributes in the

Charter also says:
"The NETEXT working group will
also act as the primary forum where new extensions on top of the Proxy
Mobile IPv6 protocol can be developed."

This work item as well as Service Selection for Mobile IPv6 will be added
to the charter milestones.

-Raj

>> A New Internet-Draft is available from the on-line Internet-Drafts
>>directories. This draft is a work item of the Network-Based Mobility
>>Extensions Working Group of the IETF.
>>
>>        Filename        :
>>draft-ietf-netext-wifi-epc-eap-attributes-00.txt
>>        Pages           : 12
>>        Date            : 2012-04-23
>>

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 25 Apr 2012 14:52:00 -0700

Hi Behcet,

Thanks for reading. Comments inline..

> PMIPv6 relevance is very tangential,

Wrong. It's similar to the PMIP6 Radius ID, of which you are a co-author :-)
You could argue that defining Radius attributes has nothing do with PMIP6,
but that's not the case - PMIP6 signaling benefits/relies on such
attributes.

The MAG needs to know few elements to populate in the PBU, such as the APN
and HI. The ID is defining those attributes using EAP, which is necessary in
non-3gpp trusted access networks.

> If you look at the call flow in Fig.1 there is no PMIPv6 at all.

Not quite.. Please read the text underneath as well.

:   o  WAC: WiFi Access Controller.  In a PMIPv6-deployed network, could
      host the MAG functionality or is assumed to have a suitable
      interface to the MAG.  In the following, we simply use "WAC"
      notation.  The MAG functionality within the WAC (or within the
      WiFi access network), or a suitable interface to MAG is assumed
      for PMIPv6 deployments."

So, either the MAG is the Authenticator (such as a NAS in your ID) or there
is a trusted interface between the Authenticator and the MAG which has
access to the EAP messages.

In the next version, I will revise Figure 1 to show this explicitly.

> authentication exchanges over Wi-Fi links.

Nope.. It is to re-use an existing and required protocol (EAP-AKA') to
provide certain functions for WiFi integration (with PMIP6 nodes), which are
lacking today.

> This seems to be so obvious.

Again, this is about making PMIP6 work in trusted WiFi integration.

The draft is defining EAP attributes for EAP Attributes registry.
These attributes are necessary for the functioning of trusted WiFi PMIP6
deployments.

Regards,

-Rajeev

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Apr 2012 17:39:41 -0500

Hi Rajeev,

draft-ietf-netext-radius-pmip6 DOES NOT extend MN.
None of the attributes defined are sent by MN.

Regards,

Behcet

---

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

Hi Basavaraj,

>>Does this raise any concerns to you?

Really?

Imagine MAG as defined in RFC 5213 (which assumes that each MN is on a
point-to-point link) is connected to a shared link.
I think the result will be disastrous. If there is only one MN, it may
be OK but as more MNs join, especially in hot spots then the problems
start.

So you can not be serious.

Regards,

Behcet

---

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

Inline:

>point-to-point link) is connected to a shared link.

We all understand the link model requirements for PMIP6. Nothing is being
changed there. 

>I think the result will be disastrous.

Why? Can you elaborate?

> If there is only one MN, it may

Why? Are you saying that the current link model for PMIP6 allows only a
single MN to attach to a WiFi AP (as an example)?
What is the basis for saying that having many MNs attach to a MAG in a
hotspot (assuming wifi) will result in problems?
Is there any work that you have done to make such a statement?

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Apr 2012 10:34:16 -0500

Hi Basavaraj,

Pls see inline.

> Is there any work that you have done to make such a statement?

As you know similar concerns have been voiced over and over again in Netext.

Isn't it time to do something on this?

Clarify that everything will work fine

or

if not, then propose solutions.

 If you look at SaMOG work in 3GPP, they repeatedly said WiFi should
provide point to point link to UEs.

Why do you think they said so if they anticipated no problems?

Behcet

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 27 Apr 2012 09:15:05 -0700

Hi Behcet:

Sorry to jump in to this thread. I'm going to respond/clarify only on one specific comment (may be tangential to your discussion), as I'm not following this thread/rest of the discussion. I want to clarify only that one part though about WLAN, PMIPv6 and SaMOG.

> Clarify that everything will work fine

It is true, WLAN access is a shared media and what we need in Proxy Mobile IPv6 is essentially the ability for the MAG to advertise unicast RA's/or in general keep multicast traffic map to a single receiver (as clarified in RFC-6085). This is today the case on WLAN access networks. A client when it sends a multicast/broadcast packet, that packet is not sensed by the other receivers directly on the air interface, as in the case of ethernet, but rather it hits the access point and its the function if the access point to stream it down with using the correct multicast keys; this in essence is giving the model that we needed, as long as the access point/WLC blocks multicast traffic from wireless clients from other wireless clients.  All most every WLAN deployment is typically configured to operate it this way. The SaMOG architecture (or the WLAN IWK document that I've published), makes that assumption with impact to link model, else SaMOG architecture (with either of S2a protocol interfaces) is broken and un deployable.

Regards
Sri

---

From: <[email-masked]>
Date: Fri, 27 Apr 2012 16:29:30 +0000

Behcet,

>As you know similar concerns have been voiced over and over again in

This is just FUD. Please explain or reference what these concerns are that
have been voiced in Netext.
If you can list these concerns clearly, I think everyone on this list
would appreciate it.

>Isn't it time to do something on this?

We canŠ If there are issues/concerns. So the ball is in your court to
explain to the WG what these issues/concerns are.

>Clarify that everything will work fine

What do you mean "everything will work fine"? Can you tell me what does
not work today? 

>Why do you think they said so if they anticipated no problems?

Please tell me why 3GPP said so. I have no idea what the details of the
SaMOG work in 3GPP are.
Maybe you can explain to the WG the reasoning of 3GPP and what those
anticipated problems are.

-Raj

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Apr 2012 11:43:40 -0500

Hi Sri,

Thanks for chipping in your valuable views on this.
Basavaraj seems to disagree that there is a problem there but I don't know why?

On Fri, Apr 27, 2012 at 11:15 AM, Sri Gundavelli <[email-masked]> wrote:
> It is true, WLAN access is a shared media and what we need in Proxy
>Mobile IPv6 is essentially the ability for the MAG to advertise unicast
>RA's/or in general keep multicast traffic map to a single receiver (as
>clarified in RFC-6085). This is today the case on WLAN access
>networks. A client when it sends a multicast/broadcast packet, that
>packet is not sensed by the other receivers directly on the air interface,
>as in the case of ethernet, but rather it hits the access point and its the
>function if the access point to stream it down with using the correct
>multicast keys; this in essence is giving the model that we needed, as l
>ong as the access point/WLC blocks multicast traffic from wireless
>clients from other wireless clients.  All most every WLAN deployment is
>typically configured to operate it this way. The SaMOG architecture (or
>the WLAN IWK document that I've published), makes that assumption
>with impact to link model, else SaMOG architecture (with either of S2a
>protocol interfaces) is broken and un deployable.
>

I wonder how do you map to a single receiver if there are more than
one receivers, i.e. the correct receiver?

You mentioned WLAN IWK document, can you provide the link?

As you know there are also Layer 2 solutions.

I think we need to document it in Netext, maybe the chairs can add a
milestone on this to the charter?

Regards,

Behcet

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 27 Apr 2012 09:45:58 -0700

> one receivers, i.e. the correct receiver?

L3-Multicast, L2 unicast to a given node. RFC 6085. This is standard stuff; There is no issue here.

Sri

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 27 Apr 2012 11:51:15 -0500

> L3-Multicast, L2 unicast to a given node. RFC 6085. This is standard stuff; There is no issue here.

I read RFC 6085.

I had that question and I could not find an answer for that? How does
the AP know "the given node"?

Anyways, I repeat my plea for documenting this issue in Netext and
clearing the air once and for all.

Behcet

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 27 Apr 2012 09:53:05 -0700

Mac address is bound to the EAP identity. The Wireless LAN Controller/Access
Point has the Mac to identity binding, which has association in the BUL
entry.

Sri

On 4/27/12 9:51 AM, "Behcet Sarikaya" <[email-masked]> wrote:

>>>> Sorry to jump in to this thread. I'm going to respond/clarify only on one
>>>> specific comment (may be tangential to your discussion), as I'm not
>>>> following this thread/rest of the discussion. I want to clarify only that
>>>> one part though about WLAN, PMIPv6 and SaMOG.
>>>> 
>>>> 
>>>>