Subject: RE: [netlmm] MN-Id overspecification

From: "Alper Yegin" <[email-masked]>
Date: Thu, 27 Sep 2007 10:50:38 +0300

Kuntal,

> Even if the HNP is included in the PBU, the user identity cannot be
> deterministically derived from that info. The HNP may be dynamically
> assigned to the users in many systems.

Whoever assigned the HNP has a chance to see the user id. Either it is
assigned during the network access authentication, in which case the user id
is best known; or it is assigned during the initial PBU in which case I say
we shall include MN-id.

But once the HNP<->MN-id binding is established like above, we no longer
need to keep sending MN-id. HNP becomes the identifier.

Alper

> The benefit of including the MN-ID (NAI) in the PMIP signaling messages
> is that it provides a unique and consistent way to identify the user at
> the LMA and the MAG at all times (i.e. initial attach and
> re-registration).
> 
> BR,
> Kuntal
> 
> 
> > -----Original Message-----
> > From: Alper Yegin [mailto:[email-masked]]
> > Sent: Wednesday, September 26, 2007 11:58 AM
> > To: 'Ahmad Muhanna'; [email-masked]
> > Subject: RE: [netlmm] MN-Id overspecification
> >
> > Ahmad,
> >
> > > In case that a HNP is available at the MAG (how: out-of-scope) and
> > > included in the initial P-BU, ...
> >
> > ... MAG is not required to include an NAI option that carries the
> > MN-identifier.
> >
> > In the spec, all we need to say is "MN-Identifier MUST be included in
> PBU
> > when the HNP is set to 0::0/0"
> >
> >
> > Alper
> >
> >
> >
> > NO NAI or any other IDs related to the MN
> > > should be included?
> > >
> > >
> > > Regards,
> > > Ahmad
> > >
> > >
> > > > -----Original Message-----
> > > > From: Alper Yegin [mailto:[email-masked]]
> > > > Sent: Wednesday, September 26, 2007 7:35 AM
> > > > To: [email-masked]
> > > > Subject: [netlmm] MN-Id overspecification
> > > >
> > > > This issue is still hanging.
> > > >
> > > > So far as I understand the MN-Id is only used for performing
> > > > HNP assignment in-band with PMIP6 signaling. In case HNP is
> > > > already assigned, there is no need to be carrying any info
> > > > that directly or indirectly points to the MN's identity.
> > > >
> > > > But on the other hand, MN-id is all over the spec with
> > > > normative languages that suggest it be present in every message.
> > > >
> > > > This is an overspecification, reducing flexibility and
> > > > getting in the ways of various deployment scenarios.
> > > >
> > > > I recommend we change the spec such that MN-id is only
> > > > mandated when HNP needs to be assigned.
> > > >
> > > > Would there be an objection to that? Is there any technical
> > > > reason to carry an identifier of the MN in every PMIP6 message?
> > > >
> > > >
> > > > Alper
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > netlmm mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/netlmm
> > > >
> >
> >
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 
> "This email message and any attachments are confidential information of
> Starent Networks, Corp. The information transmitted may not be used to
> create or change any contractual obligations of Starent Networks, Corp.
> Any review, retransmission, dissemination or other use of, or taking of
> any action in reliance upon this e-mail and its attachments by persons or
> entities other than the intended recipient is prohibited. If you are not
> the intended recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> [email-masked] -- and destroy all copies of this message
> and any attachments without reading or disclosing their contents. Thank
> you."

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 27 Sep 2007 11:30:07 +0200

> is best known; or it is assigned during the initial PBU in which case I say

I agree it sees an 'id'.  Whether that's an user id or a device address 
is a different story.

How would this assignment work with DHCP?

> need to keep sending MN-id. HNP becomes the identifier.

I'd agree if you meant "HNP+id==full_address" becomes the identifier.

Alex

>> and any attachments without reading or disclosing their contents. Thank

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Sep 2007 07:27:38 -0700

I don't understand. RFC 4285 requires MN-ID in the binding update. For 
what you want to do you would need to include the MAG-ID in addition to 
the MN-ID in the proxy binding update.

Vijay

---

From: "Muhanna, Ahmad (RICH1:2H10)" <[email-masked]>
Date: Thu, 27 Sep 2007 10:12:39 -0500

> Subject: Re: [netlmm] MN-Id overspecification
> 
> I don't understand. RFC 4285 requires MN-ID in the binding 
> update. For what you want to do you would need to include the 
> MAG-ID in addition to the MN-ID in the proxy binding update.

[Ahmad]
Actually I have the same question. I believe in another tearlier thread,
Alper wants to use the MN-ID option to carry the Proxy MN-ID, which he
said it should be the MAG-ID. My understanding that MN-ID option has a
subtype field to identify different ID's. I hope that helps here. Unless
there is a use case that I am not aware of.

Is the issue here related to: if including more than one ID options in
the P-BU is allowed?

> > assigned during the network access authentication, in which 
> case the 
> > user id is best known; or it is assigned during the initial PBU in 
> > which case I say we shall include MN-id.
> > 
> > But once the HNP<->MN-id binding is established like above, we no 
> > longer need to keep sending MN-id. HNP becomes the identifier.
> > 
> > Alper
> > 
> >> The benefit of including the MN-ID (NAI) in the PMIP signaling 
> >> messages is that it provides a unique and consistent way 
> to identify 
> >> the user at the LMA and the MAG at all times (i.e. initial 
> attach and 
> >> re-registration).
> >>
> >> BR,
> >> Kuntal
> >>
> >>
> >>> In the spec, all we need to say is "MN-Identifier MUST be 
> included 
> >>> in
> >> PBU
> >>>>> So far as I understand the MN-Id is only used for 
> performing HNP 
> >>>>> assignment in-band with PMIP6 signaling. In case HNP is already 
> >>>>> assigned, there is no need to be carrying any info that 
> directly 
> >>>>> or indirectly points to the MN's identity.
> >>>>>
> normative 
> >>>>> languages that suggest it be present in every message.
> >>>>>
> getting in 
> >>>>> the ways of various deployment scenarios.
> >>>>>
> >>>>> I recommend we change the spec such that MN-id is only mandated 
> >>>>> when HNP needs to be assigned.
> >>>>>
> >>>>> Would there be an objection to that? Is there any 
> technical reason 
> >>>>> to carry an identifier of the MN in every PMIP6 message?
> >>>>>
> >>>>>
> >>>>> Alper
> >>>>>
> >>>>>
> >>>>>
> >> "This email message and any attachments are confidential 
> information 
> >> of Starent Networks, Corp. The information transmitted may not be 
> >> used to create or change any contractual obligations of 
> Starent Networks, Corp.
> >> Any review, retransmission, dissemination or other use of, 
> or taking 
> >> of any action in reliance upon this e-mail and its attachments by 
> >> persons or entities other than the intended recipient is 
> prohibited. 
> >> If you are not the intended recipient, please notify the sender 
> >> immediately -- by replying to this message or by sending 
> an email to 
> >> [email-masked] -- and destroy all copies of this 
> >> message and any attachments without reading or disclosing their 
> >> contents. Thank you."
> > 
> >

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 27 Sep 2007 18:33:05 +0300

If the HNP is assigned during network access AAA, PMIP6 does not have to
carry the MN-Id at all. Only MAG-Id is carried for RFC 4285 auth.

Alper 

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Thursday, September 27, 2007 5:28 PM
> To: Alper Yegin
> Cc: 'Chowdhury, Kuntal'; [email-masked]
> message

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 27 Sep 2007 09:51:13 -0700

All,

<Chair Hat On>

I think this discussion has gone on long enough and is now getting into
the same points again.  The discussion of Auth protocol in this thread
at the moment is not useful.  The WG is not working on that and we
really don't have the bandwidth to spend on that right now.  

>From the various points I've seen, it appears like the MN-ID may not be
technically needed in all the messages, but, also, there doesn't seem to
be anything technically wrong with the inclusion of it.  It also appears
that most people prefer that the procedures for all the PBU/PBA
signaling be similar where possible and hence, prefer keeping the MN-ID
in all the messages. 

I note that Alper, Alex and I* (to some extent) prefer to keep it out of
messages that don't need it, but, I don't see anyone else agreeing with
that viewpoint.  So, let's move on with the conclusion that we leave the
MN-ID in the messaging as specified in the document now.  

</Chair Hat On>

Thanks,
Vidya

<Chair Hat Off>

* Although I was saying that we can keep the MN-ID out of messages that
don't need it, I don't have a strong preference.  It is not a technical
showstopper and so, I'm fine with moving on with the preference of the
WG.  

</Chair Hat Off>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 27 Sep 2007 22:15:58 +0300

Vidya,

Aren't you jumping the gun too soon?

- 3 people (Alper, Alex, Vidya) agree document is specifying something that
is not needed.
- 5 people (Ahmad, Raj, Vijay, Kuntal, Sri) have a spectrum of positions
varying between objecting to trying to understand.
- Thread has not been going on for too long or anything
- People in the WG are still struggling with the use of MN-id and what is in
MN-id in fact.

Besides, I'm not getting any solid technical reasons why the proposal should
be rejected. Can you summarize it??

" prefer that the procedures for all the PBU/PBA signaling be similar where
possible" is such a weak reason. Do you think aesthetic look of packets are
more important than getting in the way of some deployment possibilities?

Alper

Alper
Samsung 

> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Thursday, September 27, 2007 7:51 PM
> To: [email-masked]
> Subject: Concluding this thread (RE: [netlmm] MN-Id overspecification)
> 
> All,
> 
> <Chair Hat On>
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 27 Sep 2007 13:14:11 -0700

Alper,
I'm making an observation based on two aspects - 1. we seem to be
revisiting the same discussion points again; 2.  this is now becoming an
Auth protocol discussion, which is not the current focus of the group.  

Also, please note that I mentioned I'm fine with the approach of keeping
the MN-ID, given all the discussions.  So, I really see only you and
Alex objecting at this point.  Please also note that Alex drew attention
to the fact that he is not intending to discuss the Auth protocol here.

A digression on the Auth protocol discussion is not useful at the
moment.  We need to make progress on the open issues at hand and
progress the document. 

Thanks,
Vidya

> Sent: Thursday, September 27, 2007 12:16 PM
> To: Narayanan, Vidya; [email-masked]
> Subject: RE: Concluding this thread (RE: [netlmm] MN-Id 
> overspecification)
> 
> Vidya,
> 
> - 3 people (Alper, Alex, Vidya) agree document is specifying 
> something that is not needed.
> - 5 people (Ahmad, Raj, Vijay, Kuntal, Sri) have a spectrum 
> of positions varying between objecting to trying to understand.
> - People in the WG are still struggling with the use of MN-id 
> and what is in MN-id in fact.
> 
> Besides, I'm not getting any solid technical reasons why the 
> proposal should be rejected. Can you summarize it??
> 
> " prefer that the procedures for all the PBU/PBA signaling be 
> similar where possible" is such a weak reason. Do you think 
> aesthetic look of packets are more important than getting in 
> the way of some deployment possibilities?
> 
> 
> Alper
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Alper
> Samsung 
> 
> > I think this discussion has gone on long enough and is now getting 
> > into the same points again.  The discussion of Auth 
> protocol in this 
> > thread at the moment is not useful.  The WG is not working 
> on that and 
> > we really don't have the bandwidth to spend on that right now.
> > 
> > >From the various points I've seen, it appears like the 
> MN-ID may not 
> > >be
> > technically needed in all the messages, but, also, there 
> doesn't seem 
> > to be anything technically wrong with the inclusion of it.  It also 
> > appears that most people prefer that the procedures for all the 
> > PBU/PBA signaling be similar where possible and hence, 
> prefer keeping 
> > the MN-ID in all the messages.
> > 
> > I note that Alper, Alex and I* (to some extent) prefer to 
> keep it out 
> > of messages that don't need it, but, I don't see anyone 
> else agreeing 
> > with that viewpoint.  So, let's move on with the conclusion that we 
> > leave the MN-ID in the messaging as specified in the document now.
> > 
> > </Chair Hat On>
> > 
> > Thanks,
> > Vidya
> > 
> > <Chair Hat Off>
> > 
> > * Although I was saying that we can keep the MN-ID out of messages 
> > that don't need it, I don't have a strong preference.  It is not a 
> > technical showstopper and so, I'm fine with moving on with the 
> > preference of the WG.
> > 
> > </Chair Hat Off>
> >

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 28 Sep 2007 00:58:45 +0300

Vidya,

I don't know why auth protocol is such a taboo.
If it is so bad, why is IETF even trying to revise it?
Rather than introducing artificial constraints against it, IETF should do
something more meaningful.
Note that WiMAX Forum R1.0 is using that for MIP6.

...

No part of the proposal is meant to cause additional work to the WG for
supporting RFC 4285, despite how you framed it in your e-mail. In fact, not
cleaning the overspecification part prevents a RFC 4285-based deployment
scenario. Why do we want to do that?

You may be fine with keeping the extra mandates, but you also agreed it is
not necessary to keep them. Unless people want to block an RFC 4285-based
scenario, I see there is no technical justification to keep them.

If you really want to close this thread as a chair, I appreciate if you can
summarize the technical justifications to keep the current constraints in
the document despite its unintended(?) consequences. 

Alper

> Sent: Thursday, September 27, 2007 11:14 PM
> To: Alper Yegin; [email-masked]
> Subject: RE: Concluding this thread (RE: [netlmm] MN-Id overspecification)
> 
> Alper,