Subject: RE: [netlmm] Significance of MN-Identifier

From: "Alper Yegin" <[email-masked]>
Date: Wed, 12 Sep 2007 00:07:40 +0300

Hi Kuntal,

> I don't know what the issue is for MN-ID in the PMIP6 signaling
> messages. Could you explain why we are having this debate?

Because, the current text is locking all PMIP6 deployments to one security
model and not leaving any room for using anything else. And it is doing so
without a good reason (unintentionally, I believe).

> MN-ID is the unique identifier to identify the session state in the LMA.

It is necessary only of the MN does not know its HNP. As soon as it knows
the HNP (e.g., when HNP is assigned during network access authentication),
we can rely on HNP to identify the session state. 

> There are several good reasons to mandate the presence of MN-ID in the
> PBU/PBA. For example, it helps to identify the session state in the LMA
> for PMIP6 - MIP6 transition scenarios, when the LMA is collocated with a
> MIP6 HA. 

Can you elaborate on this scenario? You may have something here, but I need
to understand.

Alper

> Note that during IKEv2 exchange for MIP6, the IDi field (that
> carries the same MN-ID) in the IKE packets help identify the ongoing
> (PMIP6) session related to the MN.
> 
> Hope this helps.
> 
> -Kuntal
> 
> 
> > -----Original Message-----
> > From: Alper Yegin [mailto:[email-masked]]
> > Sent: Tuesday, September 11, 2007 3:46 AM
> > To: 'Sri Gundavelli'
> > Cc: [email-masked]
> > Subject: RE: [netlmm] Significance of MN-Identifier
> >
> > Sri,
> >
> > > At handoff, nMAG may not know the HNP of the mobile node. How does
> it
> > > communicate with the LMA about the MN, if MN-Id is not used ? That's
> > > is essential, its required in BCE and also in signaling messages.
> >
> >
> > So it is just for HNP assignment as I was saying:
> >
> > >>> Is it for the sake of identifying the MN during dynamic HNP
> > >>> assignment in-band with PMIP?
> >
> >
> > HNP can be assigned during network access authentication. I can't
> imagine
> > when this is not possible or desirable.
> >
> > That's why mandating presence of MN-id that identifies the MN is not
> > necessary, imo.
> >
> > If people can show a reason why we must also support HNP assignment
> in-
> > band
> > with PMIP, we can say:
> >
> > 	When the HNP in PBU has the value 0::/0, an NAI [RFC4283] that
> > carries 	the MN-id MUST be included in the PBU.
> >
> >
> >
> > Alper
> >
> >
> > >
> > > Sri
> > >
> > >
> > > > Alper
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >>
> > > >> Sri
> > > >>
> > > >>
> > > >>
> > > >>> -----Original Message-----
> > > >>> From: Alper Yegin [mailto:[email-masked]]
> > > >>> Sent: Monday, September 10, 2007 4:27 AM
> > > >>> To: [email-masked]
> > > >>> Subject: [netlmm] Significance of MN-Identifier
> > > >>>
> > > >>> What's the significance of MN-Identifier as carried in PBU?
> > > >>>
> > > >>> Is it for the sake of identifying the MN during dynamic HNP
> > assignment
> > > >>> in-band with PMIP?
> > > >>>
> > > >>> If so, given that the HNP may also be assigned during network
> access
> > > >>> authentication (out-of band with PMIP, as commonly done in
> > integrated
> > > >>> bootstrapping scenarios), we shall not mandate that the MN-
> > identifier
> > > >>> identifies the real MN.
> > > >>>
> > > >>> Another way of using of MN-identifier is to identify the
> > > >>> "proxy MN" (MAG)
> > > >>> with RFC 4285.
> > > >>>
> > > >>> 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: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 11 Sep 2007 18:16:22 -0400

Hi Alper,

My comments inline...

> Sent: Tuesday, September 11, 2007 4:08 PM
> To: Chowdhury, Kuntal; 'Sri Gundavelli'
> Cc: [email-masked]
[KC>] I believe, irrespective of the security model, we need the MN-ID
in the PBU/PBA.

> we can rely on HNP to identify the session state.
[KC>] If you are talking about re-registrations (binding refresh) the
MN-ID can be omitted. However, I don't see the reason for this
exception. The code and the lookup will be simpler if the MN-ID is
always included. 

> Can you elaborate on this scenario? You may have something here, but I
[KC>] Sure, please look in the MIP6-PMIP6 transitions I-D:

http://www.ietf.org/internet-drafts/draft-giaretta-netlmm-mip-interactio
ns-01.txt

> > any action in reliance upon this e-mail and its attachments by
persons
> or

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 11 Sep 2007 23:28:56 -0700

Hi Alper, 

> Sent: Tuesday, September 11, 2007 2:08 PM
> To: 'Chowdhury, Kuntal'; 'Sri Gundavelli'
> Cc: [email-masked]

HNP is dynamically generated. Initially, a MN may not have been
allocated any HNP, in that we have to send the MN identity for 
the LMA to apply the proper policy checks and allocate a prefix.
After that point, when the mobile moves to a new MAG, the MAG
on the link would likely authenticate the MN, obtain its id
before it allows the MN for network access. So, most likely
the new MAG would know the MN id as supposed to knowing its
allocated prefix, that may be in the BCE state (unless statically
configured in AAA).

Generally, I can see 3775 HA, identifying a MN with its HoA and
so not requiring the id in the signaling messages. But, in a
proxy model in combination with dynamic prefix allocation, is
it not reasonable to carry an identifier of the mobile node in
the messages ? Thats the stable identifier of the mobile node.
Its definetly more stable than an allocated prefix. The MAG may
authenticate the mobile node on the access link and will mo
t likely have some form of identifier, as supposed to it knowing
the prefix that is allocated by the LMA. Id is also required for
billing purposes as well and may very well be the corelation id.

I do not think, we introduced this id requirement, just with one
scenario in mind. Its a very natural requirement and the information
is there on the MAG. Do not know, why this would be an issue for
WiMAX case.

Sri

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 12 Sep 2007 11:42:12 +0300

Sri,

You are explaining how carrying some identifier representing the MN is
useful. Not explaining why "it MUST always be carried".

My point is two-fold:

- There is one very strong case that the HNP is allocated as part of the
network access authentication. In that case, we don't have to rely on "some
identifier representing the MN", instead HNP is already bound to the MN. HNP
becomes that identifier. 

- Use of RFC 4285 with MAG-LMA SA is one of the possible security models.
And that requires carrying the "MAG id" in the NAI. Assuming the NAI always
carries some "MN id" as the current spec does is disallowing this
possibility.

My proposal is to relax that language so that NAI is not "always" supposed
to carry a "MN id". Specific exception case is when the MN is already
assigned a HNP by an out-of band mechanisms.

Alper

> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Wednesday, September 12, 2007 9:29 AM
> To: 'Alper Yegin'; 'Chowdhury, Kuntal'
> Cc: [email-masked]

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 12 Sep 2007 10:59:26 +0200

Alper, 

please see inline... 

> Sent: 12. rujan 2007 10:42
> To: 'Sri Gundavelli'; 'Chowdhury, Kuntal'
> Cc: [email-masked]
> You are explaining how carrying some identifier representing 
> the MN is useful. Not explaining why "it MUST always be carried".
> 
> My point is two-fold:
> 
> - There is one very strong case that the HNP is allocated as 
> part of the network access authentication. In that case, we 
> don't have to rely on "some identifier representing the MN", 
> instead HNP is already bound to the MN. HNP becomes that identifier. 
> 
> And that requires carrying the "MAG id" in the NAI. Assuming 
> the NAI always carries some "MN id" as the current spec does 
> is disallowing this possibility.

Why is MAG id in the NAI option required for rfc 4285? The LMA could use the SPI from the auth option to identify the MAG. The NAI option can still carry the NAI of the MN. Would that work?

> 
> My proposal is to relax that language so that NAI is not 
> "always" supposed to carry a "MN id". Specific exception case 
> is when the MN is already assigned a HNP by an out-of band mechanisms.
> 
> Alper
> 
> 
> > > Because, the current text is locking all PMIP6 deployments to one 
> > > security model and not leaving any room for using 
> anything else. And 
> > > it is doing so without a good reason (unintentionally, I believe).
> > >
> > > It is necessary only of the MN does not know its HNP. As 
> soon as it 
> > > knows the HNP (e.g., when HNP is assigned during network access 
> > > authentication), we can rely on HNP to identify the session state.
> > >
> > 
> > allocated any HNP, in that we have to send the MN identity 
> for the LMA 
> > to apply the proper policy checks and allocate a prefix.
> > After that point, when the mobile moves to a new MAG, the 
> MAG on the 
> > link would likely authenticate the MN, obtain its id before 
> it allows 
> > the MN for network access. So, most likely the new MAG 
> would know the 
> > MN id as supposed to knowing its allocated prefix, that may 
> be in the 
> > BCE state (unless statically configured in AAA).
> > 
> > Generally, I can see 3775 HA, identifying a MN with its HoA 
> and so not 
> > requiring the id in the signaling messages. But, in a proxy 
> model in 
> > combination with dynamic prefix allocation, is it not reasonable to 
> > carry an identifier of the mobile node in the messages ? Thats the 
> > stable identifier of the mobile node.
> t likely 
> > have some form of identifier, as supposed to it knowing the prefix 
> > that is allocated by the LMA. Id is also required for 
> billing purposes 
> > as well and may very well be the corelation id.
> > 
> > is there on the MAG. Do not know, why this would be an 
> issue for WiMAX 
> > case.
> > 
> > Sri
> > 
> > 
> > 
> > 
> > 
> > >
> > > Can you elaborate on this scenario? You may have 
> something here, but 
> > > I need to understand.
> > >
> > > Alper
> > >
> > >
> > > > > 	When the HNP in PBU has the value 0::/0, an NAI 
> [RFC4283]
> that
> > > > > > >>> "proxy MN" (MAG) with RFC 4285.
> > > > > > >>>
> > > > > > >>> Alper
> > > > > > >>>
> > > > > > >>>
> > > > > > >>>

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Wed, 12 Sep 2007 12:28:29 +0200

Hi Alper, 

for my information, I guess that the following assumptions are needed (at least) to enable the solution you mention:
   - in order to identify the MN with the HNP you're assuming per-MN HNP model
   - in a per-MN HNP model, the HNP will have to be longer than 64 bits
Am I right?

Regards

federico

-----Message d'origine-----
De : Alper Yegin [mailto:[email-masked]] 
Envoyé : mercredi 12 septembre 2007 10:42
À : 'Sri Gundavelli'; 'Chowdhury, Kuntal'
Cc : [email-masked]
Objet : RE: [netlmm] Significance of MN-Identifier

Sri,

You are explaining how carrying some identifier representing the MN is useful. Not explaining why "it MUST always be carried".

My point is two-fold:

- There is one very strong case that the HNP is allocated as part of the network access authentication. In that case, we don't have to rely on "some identifier representing the MN", instead HNP is already bound to the MN. HNP becomes that identifier. 

- Use of RFC 4285 with MAG-LMA SA is one of the possible security models.
And that requires carrying the "MAG id" in the NAI. Assuming the NAI always carries some "MN id" as the current spec does is disallowing this possibility.

My proposal is to relax that language so that NAI is not "always" supposed to carry a "MN id". Specific exception case is when the MN is already assigned a HNP by an out-of band mechanisms.

Alper

> > security model and not leaving any room for using anything else. And 
> > It is necessary only of the MN does not know its HNP. As soon as it 
> allocated any HNP, in that we have to send the MN identity for the LMA 
> After that point, when the mobile moves to a new MAG, the MAG on the 
> link would likely authenticate the MN, obtain its id before it allows 
> the MN for network access. So, most likely the new MAG would know the 
> MN id as supposed to knowing its allocated prefix, that may be in the 
> Generally, I can see 3775 HA, identifying a MN with its HoA and so not 
> requiring the id in the signaling messages. But, in a proxy model in 
> authenticate the mobile node on the access link and will mo t likely 
> that is allocated by the LMA. Id is also required for billing purposes 
> is there on the MAG. Do not know, why this would be an issue for WiMAX 
> case.
> 
> Sri
> 
> 
> 
> 
> 
> >
> > Can you elaborate on this scenario? You may have something here, but 
> > I need to understand.
> >
> > Alper
> >
> >

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 12 Sep 2007 13:40:04 +0300

Hi Federico,

> for my information, I guess that the following assumptions are needed (at
> least) to enable the solution you mention:

Yes. That's the case with the base PMIP6 spec anyways.

>    - in a per-MN HNP model, the HNP will have to be longer than 64 bits

Why is that so?

Alper

> network access authentication. In that case, we don't have to rely on
> "some identifier representing the MN", instead HNP is already bound to the
> MN. HNP becomes that identifier.
> 
> And that requires carrying the "MAG id" in the NAI. Assuming the NAI
> always carries some "MN id" as the current spec does is disallowing this
> possibility.
>

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Wed, 12 Sep 2007 15:51:22 +0200

Hi Alper,

OK (minor comments inline)
Regards

federico

-----Message d'origine-----
De : Alper Yegin [mailto:[email-masked]] 
Envoyé : mercredi 12 septembre 2007 12:40
À : DE JUAN HUARTE FEDERICO
Cc : [email-masked]; 'Sri Gundavelli'; 'Chowdhury, Kuntal'
Objet : RE: [netlmm] Significance of MN-Identifier

Hi Federico,

>    - in order to identify the MN with the HNP you're assuming per-MN 

Yes. 
[FDJ] OK

That's the case with the base PMIP6 spec anyways.
[FDJ] That's what it says in the main body (5.2), indeed
Then, there's shared model in the annex

>    - in a per-MN HNP model, the HNP will have to be longer than 64 
> bits Am I right?

Why is that so?
[FDJ] What I had in mind was waste of IP@, but I guess this is arguable
Anyway, it's not specific to this thread

Alper

> De : Alper Yegin [mailto:[email-masked]] Envoyé : mercredi 12 
> septembre 2007 10:42 À : 'Sri Gundavelli'; 'Chowdhury, Kuntal'
> Cc : [email-masked]
> - There is one very strong case that the HNP is allocated as part of 
> the network access authentication. In that case, we don't have to rely 
> on "some identifier representing the MN", instead HNP is already bound 
> to the MN. HNP becomes that identifier.
> 
> always carries some "MN id" as the current spec does is disallowing 
> this possibility.
> 
> My proposal is to relax that language so that NAI is not "always" 
> supposed to carry a "MN id". Specific exception case is when the MN is 
> already assigned a HNP by an out-of band mechanisms.
> 
> Alper
> 
> 
> > > security model and not leaving any room for using anything else. 
> > > And it is doing so without a good reason (unintentionally, I believe).
> > >
> > > It is necessary only of the MN does not know its HNP. As soon as 
> > > it knows the HNP (e.g., when HNP is assigned during network access 
> > allocated any HNP, in that we have to send the MN identity for the 
> > LMA to apply the proper policy checks and allocate a prefix.
> > link would likely authenticate the MN, obtain its id before it 
> > allows the MN for network access. So, most likely the new MAG would 
> > know the MN id as supposed to knowing its allocated prefix, that may 
> > be in the BCE state (unless statically configured in AAA).
> >
> > Generally, I can see 3775 HA, identifying a MN with its HoA and so 
> > not requiring the id in the signaling messages. But, in a proxy 
> > model in combination with dynamic prefix allocation, is it not 
> > reasonable to carry an identifier of the mobile node in the messages 
> > ? Thats the stable identifier of the mobile node.
> > that is allocated by the LMA. Id is also required for billing 
> > purposes as well and may very well be the corelation id.
> >
> > > Can you elaborate on this scenario? You may have something here, 
> > > but I need to understand.
> > >
> > > Alper
> > >
> > >
> > > > > >>> Is it for the sake of identifying the MN during dynamic 
> > > > > >>> HNP assignment in-band with PMIP?
> > > > >
> > > > >
> > > > the intended recipient, please notify the sender immediately -- 
> > > > by replying to this message or by sending an email to

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Sep 2007 16:34:40 -0500

Hi Alper,
Please see comments inline.

Regards,
Ahmad

> is disallowing this possibility.

[Ahmad]
I guess this a multilayered complexity question which probably needs to
have several different threads to address them. However, we are forced
to handle them all together in a single thread! 
IMO, You already assumed the following:

1. RFC4285 is used for PMIPv6. ?
2. RFC4285 has a mechanism to securely protect P-BU and P-BA based on a
MAG-LMA SA. Similar to FA-HA AE!? :-(
3. The LMA is able to distinguish that the ID included in the BU is the
MAG-ID. 

Now: If the MAG is able to somehow identify that the ID included is the
MAG ID, then why there is a problem if the MN-ID is included.? May be I
am missing something here.

> is when the MN is already assigned a HNP by an out-of band mechanisms.

[Ahmad]
I am not sure where these series of relaxation will end up getting this
draft?

> > > > > > >>> HNP

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 12 Sep 2007 16:37:47 -0500

Sorry one typo. I meant to say: "if the LMA not the MAG ...

Now: If the LMA is able to somehow identify that the ID included is the
MAG ID, then why there is a problem if the MN-ID is included.? May be I
am missing something here.

Regards,
Ahmad

> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Wednesday, September 12, 2007 4:35 PM
> To: Alper Yegin; Sri Gundavelli; Chowdhury, Kuntal
> Cc: [email-masked]
> I guess this a multilayered complexity question which 
> probably needs to have several different threads to address 
> them. However, we are forced to handle them all together in a 
> single thread! 
> 2. RFC4285 has a mechanism to securely protect P-BU and P-BA 
> based on a MAG-LMA SA. Similar to FA-HA AE!? :-( 3. The LMA 
> is able to distinguish that the ID included in the BU is the MAG-ID. 
> 
> Now: If the MAG is able to somehow identify that the ID 
> included is the MAG ID, then why there is a problem if the 
> MN-ID is included.? May be I am missing something here.
> 
> > 
> I am not sure where these series of relaxation will end up 
> getting this draft?
> 
> > 
> > Alper
> > 
> > 
> > > > > > > >>> bootstrapping scenarios), we shall not 
> mandate that the
> > > > > > > >>> MN-
> > > > > > identifier
> > > > > > > >>> identifies the real MN.
> > > > > > > >>>

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 13 Sep 2007 12:15:17 +0300

Hi Domagoj,

> Why is MAG id in the NAI option required for rfc 4285? The LMA could use
> the SPI from the auth option to identify the MAG. The NAI option can still
> carry the NAI of the MN. Would that work?

Only the combination of SPI with some other node identifier (e.g., IP
address or NAI) can uniquely identify an SA. In the case of RFC4285, it's
the NAI.

I still don't understand why NAI must always carry MN's NAI. It's only
needed when HNP is not assigned. When it is assigned, we don't need that. 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 13 Sep 2007 12:23:17 +0300

Ahmad,

Not sure where the "multilayered complexity" is, but to re-iterate...

Another alternative to IPsec is to use RFC4285.
One mode to use RFC4285 is to rely on per-MAG-LMA SA.
In that model, "MAG" appears as the "proxy MN" (pMN).
RFC4285 security needs to authenticate the pMN.
And that's when the NAI shall identify the pMN, not a specific MN behind the
pMN.

...

Going back to the current spec now...
It assumes NAI always identifies the MN.
This is not necessary. Why such an over-specification when we cannot even
figure out how to identify the MN??

NAI shall identify the MN only when HNP is not assigned.
And let the spec be silent about whether NAI is used, or what NAI carries
when the HNP is already in the PBU.
That's the proposed change.

...

Unless we are trying to block use of RFC4285 (a separate discussion if
necessary), I cannot see any technical reason why this change is not
acceptable. 

Alper

> From: Ahmad Muhanna [mailto:[email-masked]]
> Sent: Thursday, September 13, 2007 12:35 AM