Subject: [netlmm] MN-Id overspecification

From: "Alper Yegin" <[email-masked]>
Date: Wed, 26 Sep 2007 15:34:51 +0300

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Sep 2007 15:01:44 +0200

> an identifier of the MN in every PMIP6 message?

I suggest that when DHCP is used to assign the address to the Mobile to 
use the Remote-ID or the Subscriber-ID, and not the MAG's 
'link-address'.  I don't know what you mean by MN-Id?  Is this a NAI? 
DHCP doesn't use 'MN-Id'.

I also think that the only possible ways to assign addresses on the 
mobile are: auto-forming the LL address, stateless RS/RA, stateful DHCP 
and PPP IPv6 LCP.  I think there isn't any other and the PMIP6 shouldn't 
define a new one either.

Alex

Alex

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

---

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

Hi Alper,

Let me understand your concern and your question a little more.

Is what you are saying is:

In case that a HNP is available at the MAG (how: out-of-scope) and
included in the initial P-BU, 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
> 
> 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
> 
> 
>

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 26 Sep 2007 18:13:03 +0300

> DHCP doesn't use 'MN-Id'.

MN-Id is defined as

   Mobile Node Identifier (MN-Identifier)

      The identity of a mobile node in the Proxy Mobile IPv6 domain.
      This is the stable identifier of a mobile node that the mobility
      entities in a Proxy Mobile IPv6 domain can always acquire and
      using which a mobile node can predictably be identified.  This is
      typically an identifier such as Mobile Node NAI [RFC-4282].

And used throughout the document.

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 26 Sep 2007 08:24:39 -0700

Alper,

Just a clarification. Are you saying it should be only in the initial 
Proxy BU/Proxy BAck exchange and not in the ones sent to refresh the 
binding?

In case there is a handoff from the old MAG to the new MAG, the new MAG 
does not necessarily know the home network prefix for the MN. So in this 
case the new MAG would also send a proxy BU with the MN-ID and a request 
for the prefix. The LMA would assign the same prefix again.

Vijay

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 26 Sep 2007 19:58:04 +0300

Ahmad,

> 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

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 26 Sep 2007 12:14:07 -0500

Alper,

What is the downside of including the MN-ID in all the MAG/LMA messages?
Does it break anything?
You say that it "is an overspecification, reducing flexibility and
getting in the ways of various deployment scenarios"...

How is it becoming an obstacle in any deployment scenario?

I am just wondering if you are optimizing the protocol by not including the
MN-ID or if you see this as actually being a problem.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Sep 2007 19:56:07 +0200

> And used throughout the document.

RFC4282 "Network Access Identifier" identifies a user and not a Mobile 
Node.  "MN NAI" sounds very much illogic.

The NAIs I've seen in practice are of the form "alper@domain", or 
"some-text" and the identifiers I've seen to identify a MN are of the 
form of an IP address, or MAC address.

Thus I don't understand what this "MN-Identifier" is.  Having an 
incoherent definition in the Terminology section doesn't help my 
reading, sorry.  It doesn't fit DHCP meanings for identifiers, neither 
the PPP meanings of identifiers.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Sep 2007 19:58:50 +0200

Raj, please excuse my intruding but I agree with some points of Alper's.

> What is the downside of including the MN-ID in all the MAG/LMA messages?

There's already the HoA in all MIP6 signalling why new identifiers?

> getting in the ways of various deployment scenarios"...

I agree with that phrase of Alper, it _is_ overspefication and does 
create bloat and confuses the implementer and you don't know where to 
start reading.

> How is it becoming an obstacle in any deployment scenario?

A deployment deploying NAIs doesn't understand "MN NAI".

> MN-ID or if you see this as actually being a problem.

I don't know.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Sep 2007 19:55:44 +0200

> when the HNP is set to 0::0/0"

This tends to define a new address assignment mechanism, and this is a 
very wrong way to go.  Put ::/0 in PBU and obtain a HNP in PBAck is 
wrong to do.

We already have many address auto-configuration mechanisms, we don't 
need a new one.

P-BU and P-BAck are for updating the binding MNHoA-MAGCoA, at LMA.  P-BU 
and P-BAck are not for assigning new addresses.

Alex
(OTOH I agree with you the use of various identifiers: NAI, MN-Id, HNP
  of the mobile are not clear in the document).

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 26 Sep 2007 13:08:08 -0500

Hi Alex,

> Raj, please excuse my intruding but I agree with some points of Alper's.

The IETF MLs are equivalent to "Open season"... So feel free to interrupt :)

> There's already the HoA in all MIP6 signalling why new identifiers?

When the MAG sends the PBU, there is no HoA yet.. Hence the only identifier
is an ID that was provided to the MAG during access authentication (for
example). The NAI is just one form of an ID as the definition states.

> create bloat and confuses the implementer and you don't know where to

You could also claim that it is actually a simplification since it provides
a single identifier for matching requests and responses. Anyway to implement
this protocol, you need to read the whole doc, right?

> A deployment deploying NAIs doesn't understand "MN NAI".

I guess you mean a deployment that does not use NAIs, right? The MN-NAI is
an exampe of an identifier of the MN. It does not have to be an NAI. So in a
deployment that does not use NAIs for identifying MNs, you could use other
identifiers as long as they are unique.

-Raj

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 26 Sep 2007 11:13:23 -0700

> when the HNP is set to 0::0/0"

Of course not. If the MAG is going to be presenting the home network 
prefix in the proxy binding update to the LMA, then the LMA needs to 
check if the mobile node is authorized for the home network prefix. For 
this check to happen, the MN-ID must be there in the proxy binding 
update even if the home network prefix is set to something other than 0::0.

In Mobile IPv6, the HA performs this check by getting the identifier 
from the IKEv1/IKEv2 exchange. Since we don't have a IKEv1/IKEv2 
exchange between the MN and the LMA, the proxy BU from the MAG must have 
the MN-ID.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 26 Sep 2007 21:10:19 +0200

Basavaraj Patil wrote:
> Hi Alex,
> 
> 
> On 9/26/07 12:58 PM, "ext Alexandru Petrescu" 
> <[email-masked]> wrote:
> 
>>> What is the downside of including the MN-ID in all the MAG/LMA 
>>> messages? Does it break anything?
> When the MAG sends the PBU, there is no HoA yet.. Hence the only 
> identifier is an ID that was provided to the MAG during access 
> authentication (for example). The NAI is just one form of an ID as 
> the definition states.

Right, and the problems are (1) how is that NAI provided by MN to MAG,
which protocol? and (2) how does the MAG know the HNP associated to that
NAI.

I think you leave both these two things out of scope, right?

>>> You say that it "is an overspecification, reducing flexibility 
>>> and getting in the ways of various deployment scenarios"...
>>  create bloat and confuses the implementer and you don't know where
>>  to start reading.
> 
> You could also claim that it is actually a simplification since it 
> provides a single identifier for matching requests and responses. 
> Anyway to implement this protocol, you need to read the whole doc, 
> right?

I would _very_ much like PMIP6 to provide a single identifier but it's
not the case.  There's also the HNP and the link-address.  Both these
are used to identify the node at various points in DHCP.

> I guess you mean a deployment that does not use NAIs, right?

No no I mean a deployment that uses NAIs doesn't understand MN-NAI.
Because NAI is user identifier not device identifier.  "MN-NAI" by its
name sounds as a new proposal to mix the two.

> The MN-NAI is an exampe of an identifier of the MN.

The problem with this is that people also say that the NAI has a certain
very well defined syntax (ABNF)... and that does not include strings
that might identify a MN, ie addresses.

> It does not have to be an NAI. So in a deployment that does not use
> NAIs for identifying MNs, you could use other identifiers as long as
> they are unique.

Except that I can't encode an IPv6 address in a NAI.  Or, an IPv6 
address identifies very well a MN.

Maybe we need only one _existing_ way of identifying the node throughout 
the document, not a new term.  I think that was the initial intent.  An 
ID that could work with DHCP too, and little modification to MIP6 too.

Alex

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 13:28:33 -0700

Based on a number of these discussions, the role of the MN-ID is now
confusing to me.  I've so far heard the following uses for MN-ID: 

1. To assign a HNP (this I understand)

2. To match PBAs with PBUs (I don't get this)

3. To authorize the HNP to be mapped to that MN-ID (I don't quite get
this either)

1 is clear to me and I see why an MN-ID needs to be included in the PBUs
that set the HNP to 0.  2 doesn't make sense to me, since when the HNP
is present, that is sufficient to match responses to requests.  Also, on
the matching aspect, I think the document needs clarity, since it
sometimes states that sequence numbers are used, sometimes that
timestamps are used and some other times that MN-ID is used.  It even
mandates copying of the sequence number from the PBU to the PBA for this
purpose.  We need to get this cleaned up. 

On 3, it is not clear what we are achieving. This is different from the
MIP6 case, since in MIP6, the ID is tied to HoA which is tied to the SA
and hence, if the HoA came in with the right SA, everything is good.
Here, there isn't an SA tied to anything that belongs to the MN.  So,
simply carrying the MN-ID in the PBU doesn't provide any assurance of
that ID being tied to that HNP, other than simply trusting the MAG.  So,
not carrying the MN-ID is not taking away any existing guarantee - when
the LMA receives a PBU for a given HNP, it needs to update that binding.
If the LMA is doing something additional to verify the existence of the
MN at that MAG, it has the HNP to MN-ID mapping anyway to do that. 

So, why do we need the MN-ID for anything other than 1? 

Thanks,
Vidya

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 11:13 AM
> To: Alper Yegin
> Cc: [email-masked]
> Subject: Re: [netlmm] MN-Id overspecification
> 
> Alper Yegin wrote:
> > Ahmad,
> > 
> > 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"
> 
> Of course not. If the MAG is going to be presenting the home 
> network prefix in the proxy binding update to the LMA, then 
> the LMA needs to check if the mobile node is authorized for 
> the home network prefix. For this check to happen, the MN-ID 
> must be there in the proxy binding update even if the home 
> network prefix is set to something other than 0::0.
> 
> In Mobile IPv6, the HA performs this check by getting the 
> identifier from the IKEv1/IKEv2 exchange. Since we don't have 
> a IKEv1/IKEv2 exchange between the MN and the LMA, the proxy 
> BU from the MAG must have the MN-ID.
> 
> Vijay
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 26 Sep 2007 14:06:24 -0700

Hi Vidya,

Narayanan, Vidya wrote:
> is present, that is sufficient to match responses to requests.  

You are mixing up threads here. In one thread it was claimed that it is 
used for matching proxy BU to proxy BAck. In that it was assumed there 
is no home network prefix assigned for the MN yet. Note that we don't 
have a mechanism described in the base PMIPv6 specification for the MAG 
to obtain the home network prefix without the LMA involvement.

> MN at that MAG, it has the HNP to MN-ID mapping anyway to do that. 

If the LMA did not assign the prefix for the mobile node and the MAG 
obtained it through other means, the LMA would need to check if the 
mobile node is authorized for that home network prefix. For example the 
LMA could check with the entity that did the allocation.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 26 Sep 2007 16:43:27 -0500

Hi Vidya,

Please see comments inline.

Regards,
Ahmad

> Subject: RE: [netlmm] MN-Id overspecification
> 
> 
> Based on a number of these discussions, the role of the MN-ID 
> is now confusing to me.  I've so far heard the following uses 
> for MN-ID: 
> 
> 3. To authorize the HNP to be mapped to that MN-ID (I don't 
> quite get this either)
> 
> 1 is clear to me and I see why an MN-ID needs to be included 
> in the PBUs that set the HNP to 0.  

> 2 doesn't make sense to me,
 
[Ahmad-START-1]
I am not sure what do you mean here. Earlier you agreed that it is
needed but now I am confused. Let me give more details here:

1. PMIPv6 base protocol supports both timestamp and SQN, NO?
2. Also, as we all know, SQN needs to be tracked on a per-MN basis.
3. SQN field is restricted to 2 bytes i.e. =~ 64k. 
4. In this case, there is a very high probability that there will be
collisions of the SQN of the outstanding P-BU(s).
5. This means that MN1 and MN101 have the same SQN=xyz inserted in their
respected P-BU messages.
6. When MAG receives the P-BA for MN101, according to RFC3775, MAG needs
to find the matching P-BU based on SQN xyz.

7. okay, there are two P-BU(s) that are outstanding waiting for reply.
Right?
7.1. How the MAG needs to know which MN the P-BA belongs to?
7.2. MAG needs to use NAI to differentiate. Right?

Why then this does not make sense?

[Ahmad-END-1]

> match responses to requests.
> Also, on the matching aspect, I 
> think the document needs clarity, since it sometimes states 
> that sequence numbers are used, sometimes that timestamps are 
> used and some other times that MN-ID is used.  

[Ahmad-START-2]
The same concept actually applies to timestamp too. However, in the case
of time stamp, the possibility of collision is way much less. In other
words, it is needed either way.

May be what you are saying is the draft needs to use more details to
explain this, but I guess when it comes to SQN, the original text
already in RFC3775.

[Ahmad-END-2]

> It even 
> mandates copying of the sequence number from the PBU to the 
> PBA for this purpose.  We need to get this cleaned up.

[Ahmad-START-3]

What do you expect LMA should return a SQN of ZERO. On the other hand,
there is no indication of what the MAG is using the SQN for. Returning
the SQN is the proper approach.

[Ahmad-END-3]
> MIP6 case, since in MIP6, the ID is tied to HoA which is tied 
> to the SA and hence, if the HoA came in with the right SA, 
> everything is good.
> Here, there isn't an SA tied to anything that belongs to the 
> MN.  So, simply carrying the MN-ID in the PBU doesn't provide 
> any assurance of that ID being tied to that HNP, other than 
> simply trusting the MAG.  
> So, not carrying the MN-ID is not 
> taking away any existing guarantee - when the LMA receives a 
> PBU for a given HNP, it needs to update that binding.
> If the LMA is doing something additional to verify the 
> existence of the MN at that MAG, it has the HNP to MN-ID 
> mapping anyway to do that. 
> 
> > check if the mobile node is authorized for the home network prefix. 
> > For this check to happen, the MN-ID must be there in the 
> proxy binding 
> > update even if the home network prefix is set to something 
> other than 
> > 0::0.
> > 
> identifier 
> > exchange between the MN and the LMA, the proxy BU from the MAG must 
> > have the MN-ID.
> > 
> > Vijay
> >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 17:51:08 -0700

Hi Ahmad,
In the case of matching, I did acknowledge that it may be needed when
the HNP is set to 0.  For any other value of the HNP, the HNP can
sufficiently match the messages, can it not? 

Regards,
Vidya 

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 2:43 PM
> To: Narayanan, Vidya; Vijay Devarapalli; Alper Yegin
> Cc: [email-masked]
> quite get 
> > 1 is clear to me and I see why an MN-ID needs to be included in the 
> > PBUs that set the HNP to 0.
> 
> I am not sure what do you mean here. Earlier you agreed that 
> it is needed but now I am confused. Let me give more details here:
> 
> 4. In this case, there is a very high probability that there 
> will be collisions of the SQN of the outstanding P-BU(s).
> 5. This means that MN1 and MN101 have the same SQN=xyz 
> inserted in their respected P-BU messages.
> 6. When MAG receives the P-BA for MN101, according to 
> RFC3775, MAG needs to find the matching P-BU based on SQN xyz.
> 
> > think the document needs clarity, since it sometimes states that 
> > sequence numbers are used, sometimes that timestamps are 
> used and some 
> The same concept actually applies to timestamp too. However, 
> in the case of time stamp, the possibility of collision is 
> way much less. In other words, it is needed either way.
> 
> May be what you are saying is the draft needs to use more 
> details to explain this, but I guess when it comes to SQN, 
> the original text already in RFC3775.
> 
> [Ahmad-END-2]
> 
> > It even
> > mandates copying of the sequence number from the PBU to the PBA for 
> > this purpose.  We need to get this cleaned up.
> 
> [Ahmad-START-3]
> 
> What do you expect LMA should return a SQN of ZERO. On the 
> other hand, there is no indication of what the MAG is using 
> the SQN for. Returning the SQN is the proper approach.
> 
> [Ahmad-END-3]
> > 
> > MIP6 case, since in MIP6, the ID is tied to HoA which is 
> tied to the 
> > SA and hence, if the HoA came in with the right SA, everything is 
> > good.
> > that ID being tied to that HNP, other than simply trusting the MAG.
> > taking away any existing guarantee - when the LMA receives 
> a PBU for a 
> > given HNP, it needs to update that binding.
> > If the LMA is doing something additional to verify the existence of 
> > the MN at that MAG, it has the HNP to MN-ID mapping anyway 
> to do that.
> >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 26 Sep 2007 18:20:49 -0700

Hi Vijay, 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 2:06 PM
> To: Narayanan, Vidya
> Cc: Alper Yegin; [email-masked]
> > PBUs that set the HNP to 0.  2 doesn't make sense to me, since when 
> > the HNP is present, that is sufficient to match responses 
> to requests.
> 
> You are mixing up threads here. In one thread it was claimed 
> that it is used for matching proxy BU to proxy BAck. In that 
> it was assumed there is no home network prefix assigned for 
> the MN yet. 

Yes, as I just wrote in my response to Ahmad, this is correct.  But, in
this thread, we were discussing if the MN-ID is needed for every
message.  I was getting at the point that it is not needed in every
PBU/PBA for the purpose of matching.  

> Note that we don't have a mechanism described in 
> the base PMIPv6 specification for the MAG to obtain the home 
> network prefix without the LMA involvement.
> 

Ack. 

> > SA and hence, if the HoA came in with the right SA, 
> everything is good.
> > So, not carrying the MN-ID is not taking away any existing 
> guarantee - 
> > when the LMA receives a PBU for a given HNP, it needs to 
> update that binding.
> If the LMA did not assign the prefix for the mobile node and 
> the MAG obtained it through other means, the LMA would need 
> to check if the mobile node is authorized for that home 
> network prefix. For example the LMA could check with the 
> entity that did the allocation.
> 

Given what you just said above (i.e., we can only allocate prefixes
through the LMA), how is this valid?  But, let's suppose it is and the
MAG obtained the prefix from an independent entity.  How can we assume
that the identity used to obtain the prefix from the independent entity
is the same as the MN-ID presented in the PBU?  Given that we don't
define that independent mechanism of obtaining prefixes, we can't make
this assumption, right? 

Vidya

> >> For this check to happen, the MN-ID must be there in the proxy 
> >> binding update even if the home network prefix is set to something 
> >> other than 0::0.
> >>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 26 Sep 2007 21:35:57 -0700

> PBU/PBA for the purpose of matching.  

I asked the WG to comment on the issue of Timestamp vs Seq Number,
this was some time in the Month of May 1st week. The following
consensus was explicitly noted. Please note clearly the mandate
for returning MN-Id in the PBA's. This was discussed in the NETLMM
WG.

http://www1.ietf.org/mail-archive/web/netlmm/current/msg02200.html

Now, if we say, may be its not required for re-registrations, I 
dont believe in that fuzzy logic, its adds implementation
complexity. 

Before reopening things that have been agreed upon, let there be
a good reason. 

Sri

---

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

Vijay,

I don't make any distinction between initial vs refresh.
The same rule applies: MN-id is only mandated when HNP needs to be assigned.

If a refresh lacks the HNP, it must have the mn-id.

Alper 

> Sent: Wednesday, September 26, 2007 6:25 PM
> To: Alper Yegin
> Cc: [email-masked]

---

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

Raj,

> What is the downside of including the MN-ID in all the MAG/LMA messages?

As I had explained earlier, one way to deploy PMIP is to use RFC 4285 with
per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In that case, HNP
can be assigned during network access authentication (so, we no longer need
to convey the id of the "MN" in-band with PMIP), but we need to convey the
id of the "proxy-MN (MAG)" for PMIP security. 

That scenario breaks when we unnecessarily force the protocol to always
carry "MN"-id.

Even without this I could be arguing against this overspecification based on
lack of need and uncertainty around what to put in MN-id.

Alper

---

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

> update even if the home network prefix is set to something other than

What really needs to be authorized is the "MAG" for sucking in all the
traffic destined for a HNP. Checking if the MN-id and HNP matches is
meaningless next to this one. In order to do the former, the system
internally needs to perform the latter. 

Let me be more specific, but note that these are outside scope of PMIP6
spec.

During network access authentication, the home network associates MN and
MAG. Since we care about protecting the HNP, home network already knows the
MN and HNP association. So, when the MAG sends the PBU, home network can
check if the requested HNP matches those of MNs that are associated with the
MAG. See that does not involve carrying the MN-id (when HNP is present in
the PBU).

Alper

---

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

> lack of need and uncertainty around what to put in MN-id.

Alper, please don't try to bring in 4285 via MN-Id.

I don't support 4285 for PMIPv6.

4285 and draft-4285bis are _very_ poorly specified and are being 
currently discussed in MIP6.  Many issues that I've raised haven't been 
dealt with, but I will not hesitate to re-raise them again when time 
comes, on that list.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 27 Sep 2007 08:03:01 -0500

Hi Vidya,

I also acknowledged earlier that it can.
However, that adds complexity to the MAG and the LMA. If we need the
MN-ID for the initial P-BU what prevents us from including it in the
re-registration P-BU.

As I said earlier in my other reply to your question, unless there is a
serious advantage for not including the MN-ID in the re-registration
P-BU, we SHOULD keep the MN-ID in all P-BU. Otherwise, it complicates
Interoperability between MAGs and LMAs etc.

Regards,
Ahmad

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 7:51 PM
> To: Muhanna, Ahmad (RICH1:2H10); Vijay Devarapalli; Alper Yegin
> Cc: [email-masked]
> In the case of matching, I did acknowledge that it may be 
> needed when the HNP is set to 0.  For any other value of the 
> HNP, the HNP can sufficiently match the messages, can it not? 
> 
> Regards,
> Vidya 
> 
> > 5. This means that MN1 and MN101 have the same SQN=xyz inserted in 
> > their respected P-BU messages.
> > 6. When MAG receives the P-BA for MN101, according to RFC3775, MAG 
> > needs to find the matching P-BU based on SQN xyz.
> > 
> > The same concept actually applies to timestamp too. However, in the 
> > case of time stamp, the possibility of collision is way 
> much less. In 
> > other words, it is needed either way.
> > 
> details to 
> other hand, 
> > > On 3, it is not clear what we are achieving. This is 
> different from 
> > > the
> existence of

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 27 Sep 2007 07:17:13 -0700

Hi Alper,

Assuming we relax the MUST requirement on the presence of
MN-Id and when the MAG is aware of the MN-HNP, but, how do
you plan to carry the Auth Option in PBU's. The spec defines
HNP, TS, NAI, Link-local address options to be carried in PBU
and PBA's. Any other options, such as MNP option from 3963
or Auth Option from 4285 are not defined for these messages.

Sri 

> Sent: Thursday, September 27, 2007 12:37 AM
> To: 'Basavaraj Patil'; 'Ahmad Muhanna'; [email-masked]
> > I am just wondering if you are optimizing the protocol by 
> not including
> > the

---

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

Alper,

> internally needs to perform the latter. 

We require both.

> MAG. 

Assigning the home network prefix during access authentication would 
involve something like the AAA server managing the home network prefixes 
pool. I don't see any advantages with that. Do you keep updating the AAA 
database everytime something changes on the LMA?

> Since we care about protecting the HNP, home network already knows the

Lets assume its the AAA server that did the assignment. The LMA would 
need to check with the AAA server if the MAG is using the right home 
network prefix for a particular mobile node. What if the MAG mixed up 
the prefixes for two mobile nodes attached to it both authenticated by 
the same AAA server? This would require the LMA knowing the MN-ID and 
the home network prefix when the proxy BU is received at the LMA. So you 
have to include the MN-ID in the proxy BU.

Alper, frankly I think you need to show why including the MN-ID in the 
proxy BU is a bad idea. If there is no issue, lets move on.

Vijay

---

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

Hi Sri,

> or Auth Option from 4285 are not defined for these messages.

Unless the PMIP6 spec explicitly disallows use of Auth Option, I don't think
it needs to explicitly support it (assuming we straighten the wrinkle we are
discussing).

Alper

---

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

Vijay,

> database everytime something changes on the LMA?

Vijay, you are confusing me. If there is no known (to AAA) association
between the MN and the HNP, why do you care to check the MN-id???? You said
" LMA needs to check if the mobile node is authorized for the home network
prefix" Where is the base of that check coming from?

> have to include the MN-ID in the proxy BU.

I don't understand this example at all. I don't understand the mix up, and
why we would be dealing with a MAG that "mixes up things". 

> proxy BU is a bad idea. If there is no issue, lets move on.

Frankly, I did show it on the ML twice already. And yet to see why it is
useful (other than for the HNP assignment case).

Alper

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Sep 2007 08:34:02 -0700

> prefix" Where is the base of that check coming from?

The sequence would be as follows for your scenario (assuming your 
scenario is to allocate HNP during access authentication)

- MN does access authentication
- AAA server sends the HNP for the MN to the MAG
- MAG sends a proxy BU with the MN-ID and the HNP to the LMA
- LMA checks if the MN-ID is authorized for the HNP (with AAA's help)

Note that I completely disagree with the AAA server assigning the HNP. I 
would like HNP assignment always coming from the LMA.

> useful (other than for the HNP assignment case).

With 4285? That was hardly convincing. Sorry.

Vijay

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Thu, 27 Sep 2007 19:15:59 +0200

Hi Alper,

I don't quite understand why the security solution you advocate for is exclusive with in-band HNP assignment
If I've understood clearly what you're trying to enable, I wonder if it would suit you to have 2 NAIs: MN-NAI and MAG-NAI
Then you could specify that the MAG-NAI is the one to be used for 4285 purposes (wherever this is defined)

Regards

federico

-----Message d'origine-----
De : Alper Yegin [mailto:[email-masked]] 
Envoyé : jeudi 27 septembre 2007 09:37
À : 'Basavaraj Patil'; 'Ahmad Muhanna'; [email-masked]
Objet : RE: [netlmm] MN-Id overspecification

Raj,

> What is the downside of including the MN-ID in all the MAG/LMA messages?

As I had explained earlier, one way to deploy PMIP is to use RFC 4285 with per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In that case, HNP can be assigned during network access authentication (so, we no longer need to convey the id of the "MN" in-band with PMIP), but we need to convey the id of the "proxy-MN (MAG)" for PMIP security. 

That scenario breaks when we unnecessarily force the protocol to always carry "MN"-id.

Even without this I could be arguing against this overspecification based on lack of need and uncertainty around what to put in MN-id.

Alper

> I am just wondering if you are optimizing the protocol by not 
> including the MN-ID or if you see this as actually being a problem.
> 
> -Raj
> 
> 
> > 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.
> >>>
> >>> 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
> >>>
> >>>
> >>>

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 27 Sep 2007 12:50:48 -0500

Alper,

> id of the "proxy-MN (MAG)" for PMIP security.

To use RFC4285 for PMIP6, you will need to specify how this is used. I think
Sri stated something similarly that the extensions needed in PMIP6 messages
for using 4285 cannot be simply used as is.

> That scenario breaks when we unnecessarily force the protocol to always

I don't think it breaks. Having MN-ID in addition to another parameter
should solve your issue.

> lack of need and uncertainty around what to put in MN-id.

Lack of need in subsequent messages is what I think you are refering to and
that seems to be the general view. An example of what the MN-ID possibly is,
is given in the ID, i.e the NAI. Any other ID types can be used but will
need to be registered in IANA.

-Raj

---

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

> - LMA checks if the MN-ID is authorized for the HNP (with AAA's help)

Yes.

> would like HNP assignment always coming from the LMA.

If you prefer that in your deployments, fine by me. But if you somehow want
to force any IETF spec to limit deployments in that way, we need to discuss
that.

> With 4285? That was hardly convincing. Sorry.

Do you have any technical feedback, or is it just that you don't feel like
being convinced? 

Alper

---

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

Raj,

> for using 4285 cannot be simply used as is.

I responded to Sri (I don't see why "cannot").

> I don't think it breaks. Having MN-ID in addition to another parameter

Will respond via Federico's email.

Yes.

> need to be registered in IANA.

You mean the NAI used during the network access authentication? By now it is
understood that does not work. NAI may lack uniqueness (e.g., just realm
used w/o username), or change from one auth to another. It's such an
unstable non-unique id.

Alper

---

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

Hi Federico,

> If I've understood clearly what you're trying to enable, I wonder if it
> would suit you to have 2 NAIs: MN-NAI and MAG-NAI

Raj and Ahmad also suggested that.

The problem is, RFC 4285 does not accommodate that. It expects the
identifier be in "MN-NAI mobility option as defined in [RFC4283]". If PMIP6
spec uses a suboption type other than type 1 (MN-NAI) then it works.
Otherwise this breaks RFC 4285. 

Alper

> per-MAG-LMA SA where we perceive the MAG as the proxy-MN. In that case,
> HNP can be assigned during network access authentication (so, we no longer
> need to convey the id of the "MN" in-band with PMIP), but we need to
> convey the id of the "proxy-MN (MAG)" for PMIP security.
> 
> Even without this I could be arguing against this overspecification based
> on lack of need and uncertainty around what to put in MN-id.
> 
> Alper
> 
> 
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 27 Sep 2007 13:44:42 -0700

Hi Alper,  

> Otherwise this breaks RFC 4285. 

If you use Auth Option in PBU/PBA's, you will break PMIP6.
The options are not defined for PBU/PBA's. No guidance on
how LMA interpret that option. If you use MN-NAI, it will
break 4285. Either case, to use 4285, you will have to
break one of them. On a lighter note, I'd say, you should
break 4285. It is broken any ways. 

I really think what Federico/Ahmad suggesting is ok. Small
deviation from 4285.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 27 Sep 2007 18:26:47 -0700

>> - LMA checks if the MN-ID is authorized for the HNP (with AAA's help)

If you agree with the above, it means the LMA needs to have the MN-ID 
when the proxy BU is processed. Does this not mean, it is carried in the 
proxy BU.

> to force any IETF spec to limit deployments in that way, we need to discuss

You can of course disagree.

> Do you have any technical feedback, or is it just that you don't feel like

Hard to give technical feedback on something that is not technically 
convincing. :)

Vijay

---

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

Narayanan, Vidya wrote:
> is the same as the MN-ID presented in the PBU?  

We do have an assumption that the identity that the mobile node used for 
access authentication to the MAG is the same as the identity carried in 
the proxy BU.

> Given that we don't

Here we have an assumption that the "independent mechanism to obtain the 
prefix" is tied to access authentication.

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 28 Sep 2007 01:01:17 -0500

Vijay,
Let me add one comment below.

Regards,
Ahmad

> If you agree with the above, it means the LMA needs to have 
> the MN-ID when the proxy BU is processed. Does this not mean, 
> it is carried in the proxy BU.

[Ahmad]
In case that LMA needs to contact AAA server for this authorization
which is very much expected during initial registration, how the LMA
would know which AAA server it needs to forward the RADIUS or DIAMETER
request if P-BU ONLY has the HNP?

Is there a mechanism which allows the LMA to identify the MN home AAA
server based on HNP?

Regards,
Ahmad

> 
> >> Note that I completely disagree with the AAA server assigning the 
> >> HNP. I would like HNP assignment always coming from the LMA.
> > 
> > If you prefer that in your deployments, fine by me. But if 
> you somehow 
> > want to force any IETF spec to limit deployments in that 
> way, we need 
> > to discuss that.
> 
> >>>> Alper, frankly I think you need to show why including 
> the MN-ID in 
> >>>> the proxy BU is a bad idea. If there is no issue, lets move on.
> >>> Frankly, I did show it on the ML twice already. And yet 
> to see why 
> >>> it is useful (other than for the HNP assignment case).
> > Do you have any technical feedback, or is it just that you 
> don't feel 
> > like being convinced?
> 
> Hard to give technical feedback on something that is not 
> technically convincing. :)
> 
> Vijay
> 
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 28 Sep 2007 04:36:29 -0700

> Is there a mechanism which allows the LMA to identify the MN home AAA

No. The MN-ID (in the form of NAI) would be required again.

Vijay