Subject: [netlmm] Review of draft-ietf-netlmm-proxymip6-05

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 25 Sep 2007 01:42:07 -0700

All,
The following is a review of version 05 of the base draft.  Please let
me know if any of this has been addressed in 06 and I'll take a look.
Also, if some of these are duplicates from other reviws, please feel
free to point me to a response you have provided earlier on this.  I
tried filtering out some of the duplicate comments, but, it is likely
that there are some. 

There are a number of comments below.  I've tried categorizing the
comments into "Technical - Major" (for those that are definitely going
to need some discussion), "Technical - Minor" (for those that may need
some discussion, but, aren't generally show-stoppers) and "Editorial"
(don't need discussion).  Hope that helps to some extent. 

Thanks,
Vidya

Technical - Major: 
==================

- Terminology: Proxy-CoA and MN-HoA: 

As I've mentioned before, this terminology continues to be confusing,
especially, when we talk about PMIP6 and MIP6 together.  Given that an
MN is called an MN in the MIP6 case, tagging "MN" before the HoA is not
making it any more descriptive to the PMIP6 use.  I've stated my
concerns with these terms before and I know the authors had a strong
preference to keeping this terminology, but, I'd strongly urge some
re-thinking here to avoid confusion to the end users of the protocol.  

- MN Identifier: 

Page 15 (and other parts of the document) talks about getting the MN ID
from the NAI option.  Isn't NAI just one allowed type of identity?  A
particular deployment may use other types of identities, the only
requirement being a unique identity that can be stable within the PMIP
domain.  

- Unauthorized PBUs: 

What is the purpose of sending an error code in a PBA for an
unauthorized PBU?  I would imagine that unauthorized PBUs are better
silently discarded. 

- Prefix allocation and multihomed MNs: 

The first bullet on page 18 states that the LMA "MUST ensure the
allocated prefix is not in use by any other mobile node".  In the
context of regular IP nodes that are multihomed, we discussed how it is
problematic when the same prefix/address is allocated to multiple
interfaces of the same node.  To prevent that problem, are we assuming
that every distinct interface of an MN attached to the PMIP domain has a
different unique identity?  If so, that needs to be stated. IMO, that
may not be practical, especially, if an NAI is used as the MN ID.  So,
in those cases, we really need to ensure that the LMA is not allocating
the same prefix to multiple interfaces of a multihomed MN.  I think an
appropriate rewording of this sentence may be something like "the LMA
MUST ensure the allocated prefix is not already in use, i.e., there is
no existing BCE for that prefix on the LMA". 

I also recall that the document is supposed to state that the protocol
does not support multihomed MNs more generically, but, I couldn't find
such text.  Did I miss it? 

- Page 18, Binding De-registration: 

If the LMA may accept or ignore a PBU sent with a source address
different from the Proxy-CoA, what is that test needed for?  Are there
any examples of cases where the LMA behavior would be one or the other?
And, why is the source address relevant for a de-registration alone and
not for other PBUs? 

- MinDelayBeforeBCEDelete Timer: 

I understand where this timer is coming from, but, I'm not sure I
understand the behavior of the LMA fully when that timer is running.
For instance, when that timer is active, what happens to any data
received by the LMA for that MN? If that is sent to the CoA in the BCE,
that is of no use.  If that data is dropped, then, it is equivalent to
not having a BCE for that MN.  So, I'm not exactly sure what that timer
is achieving, other than avoiding giving up the HNP too soon.  If that
is the only intent, then, I'd word it as such and not say that the BCE
is active.  Otherwise, the processing of data packets during that
interval needs to be better defined. 

- NAI option in the PBA: 

Why is it needed? 

- Section 6.2, MN Policy Profile:

I'm not sure why this is mandatory.  For e.g., if a network has a policy
to dynamically acquire an identity for the MN and assign an available
HNP to that MN, it is not tied to "policy" in any way.  Also, when a
policy profile is present, why is the LMA address a mandatory field in
it?  That seems to be one way of obtaining the LMA address, but, there
can be other ways. 

- Creating RAs at the MAG: 

How does the MAG obtain the parameters other than the prefix needed for
the RA? For instance, the flags or other options that need to be sent?
Section 6.4 vaguely mentions based on policy, but, I don't think that is
good enough.  I think we need to have at least one mode of obtaining
that information specified as normative for implementation purposes. 

- Section 6.6, first bullet: 

I don't understand what it means for the MAG to authenticate the MN
based on an identifier.  It is not the role of the MAG to authenticate
the MN and it is really irrelevant to the PMIP6 protocol.  If the MAG
acquires the identity of an MN that has been allowed to access the
system (presumably with or without some access authentication), it must
use that identity for PMIP6.  Other than that, I don't quite understand
the MUSTs in this bullet. 

- Page 35, Timestamp values in retransmitted PBUs: 

As Suresh said, I don't think the timestamp needs to be updated in a
retransmitted PBU.  The timestamps are used for ordering, not replay
protection here.  Replay protection is provided by the IPsec SA (and
must be provided by any other authentication mechanism in use).  Having
said that, it is typically easier for retransmissions to not have to
alter the packet being sent.  Plus, that will help the LMA be idempotent
and just respond with the previously sent PBA (if there was one).  In
general, this is better to handle DoS attacks too. 

- Section 6.11, DHCP Relay Agent: 

This section seems weak.  Based on list discussions, there probably is
already a plan to elaborate on the role of the MAG as a relay agent.  

- Section 6.13, last bullet: 

I'm not sure if absence of data from the MN is an adequate enough
indication of MN detachment.  If we were to say that, it should read
"absence of data to/from the MN", since the MN may just be receiving
data and not sending anything.  But, also, it is not clear what a
"certain duration of time" is, since we don't want the MN to be
deregistered while it is in idle mode, for instance. 

- Security considerations: Authorization of MAGs: 

It is fine to have the method of authorizing a MAG be out of scope for
the specification itself, but, I think we need to give some hints on
what that means in the security considerations section.  For instance,
it could be about that particular MAG just having an IPsec SA with that
LMA or it could be something more like that MAG being part of the
defined PMIPv6 domain and the corresponding MN-HoA belonging to that
domain, etc.  

- Security considerations: MAG Compromise: 

Similar comment to the one above.  I think we need a bit more detail on
ensuring the MN is "definitively attached" to the MAG that sent the PBU.
For instance, it could be a AAA check upon reception of a PBU (the
document alludes to this somewhere), it could be a CGA signature of the
MN carried from an secure RS, in the PBU (this needs more thinking),
etc.  Again, it is fine that this document doesn't define anything
normative here, but, the security considerations as written is hand
waving this point. 

Technical - Minor: 
==================

- Page 5: PMIPv6 Domain definition: 

Isn't a PMIP domain also the topological boundary within which the MN
doesn't need to change its IP address?  It would make sense to state
that as part of the definition in my view. 

- General: 

Parts of the document contains text on IPv4.  I suggest leaving the IPv4
text to the IPv4 document. 

- Terminology: MN's Home Link: 

The use of the term "link" in this paragraph seems a bit confusing.  The
first use of it gives the impression that it is referring to an
interface on the MN, but, then, goes to say something about conceptually
following the MN.  Could we try to reword this for clarity? 

This is also the case in certain other parts of the document.  For
instance, the document refers to the PMIPv6 domain appearing as a
"single link" to the MN - this is a bit misleading.  "Link", for
instance, could be an L2 aspect, where the MN actually realizes that a
change in it's link has occurred at L2 - it is the IP point of
attachment that is being kept constant here in the PMIP6 domain.  I
think some more clarity there will be helpful.  

- Section 5.2: 

Shouldn't the first point be that the LMA should recognize the incoming
packet as a PBU, based on the P flag? 

- Section 5.2, bullet 6: 

Given that we only have a SHOULD on the use of IPsec, the second
sentence there should probably read something like "When IPsec is used
for message authentication, the SPI in the IPsec header of the received
packet MUST be used for locating..."

- Page 17, last bullet: 

Does this imply that the MN ID must always be present in the PBU?  Once
an HNP is allocated, isn't that sufficient to indicate the binding that
needs to be refreshed?  In that case, we don't need the MN ID to be
present in subsequent BUs.

- Timestamp values: 

In the 4th bullet from the bottom on page 22, it says "MUST be close
enough" of the LMA's clock - I don't think "close enough" is sufficient
here.  For interoperability, I believe we should specify the range for
closeness. 

- "SHOULD" for access authentication: 

I'm not sure why this is a SHOULD for this specification.  Just because
access authentication is likely to be done on systems that are looking
at adopting PMIP6 today doesn't make it a requirement for the protocol.
In my view, there is no depedency between having acces control versus
not from a PMIP perspective. 

- Section 6.6, MN identity: 

We should mention that this could be a link layer address or pretty much
any identifier that uniquely identifies the MN in that domain. 

- Page 33, Timestamp synchronization: 

Why do we prevent the MAG from using the LMA's timestamp value in the
PBA to synchronize its clock?  If we specify the acceptable drift
correctly and if the MAG has an idea about average transmission delays
of the network, it should be feasible.  Or, am I missing something? 

- Page 34, Binding De-registration: 

Why is this a MUST? If another MAG sends a PBU for the MN, the existing
entry will be overwritten anyway.  If not, the binding will eventually
time out.  It seems like a SHOULD for de-registration is sufficient. 

- Section 7, MN behavior: 

Given that this section is non-normative, I think phrases like "it is
recommended" or "it is important/critical" should be changed.  It sends
the impression that those are really important for the protocol even
though an IP node implementation is not expected to change.  I think
phrasing those as "the protocol would benefit from X" or "lower latency
can be achieved by doing Y" would be more appropriate.  

Editorial: 
==========

- Page 2: Abstract: 

s/network being in control of the mobility management/network being
responsible for IP mobility management of mobile nodes. 

- Page 4: Intro: 

s/The proxy mobility agent/A mobility agent 

"proxy mobility agent" sounds like a new term, while mobility agent has
been used before in the context of home and foreign agents.  We are
referring to one such agent here. 

- Page 5: LMA definition: 

s/and with the additional/with the additional 

- Page 6: MN definition: 

s/Through out/ Throughout

- Page 7: s/The local mobility is responsible/The local mobility agent
is responsible

- Page 12: s/making it believe its still on/ making it believe it is
still on

- Section 5.1: 

It would be good to add a sentence on the significance of the MN's link
local address in the BCE of the LMA.  This isn't stated until section
6.8 and even there, it is a bit buried. 

- Section 5.2: The first sentence reads as if there is only one
exception to the processing rules of RFC3775, but, there is a long list
of additional considerations.  I suggest wording it to say that
additional considerations apply and leaving the "one exception" part out
of the sentence.  

- s/IPSec/IPsec for all instances

- Page 20, last bullet: 

The use of MUST/SHOULD with IPsec should be made consistent - for e.g.,
here, it should read that the message MUST be authenticated and IPsec
SHOULD be used for that. 

- Page 21, first bullet: s/header, /header

- Page 21, Section 5.4: 

s/absence of context transfer mechanism/absence of mechanisms such as
context transfer between MAGs

- Page 21, last paragraph: 

I think we should avoid normative language for the sequence number case,
given that we don't define that here.  So, all the "MUSTs" should be
changed to read as what needs to happen in the case of sequence number
use in regular expression.  Please note that "must" is equivalent to
"MUST" per RFC2119 :) 

- Page 25, last sentence of section 5.6

Reword to "This may be obtained through mechanisms outside the scope of
this document, e.g., configuration as part of the mobile node's policy
profile." 

- Section 5.8: 

It would be good to clearly state that RO is out of scope for this
document. The section currently only says RR cannot be used. 

- Page 27, first bullet: 

s/access link or through/access link through

- Page 27: 

s/This address is acquired from/This address may be acquired from 

A preconfigured LMA address as part of MN's policy profile is only one
possibility. 

- RFC2461/2462 references should change to 2461bis and 2462bis

- Page 33: s/SHOULD not/SHOULD NOT

- Page 34/35: The "MUST construct" seems to be at odds with the SHOULDs
that follow.  

- Page 35: s/when ever/whenever

- Page 35: s/what ever reasons/whatever reason

- Page 39, Section 6.10.4: 

s/this has an implication on the mobile node's accounting/in some
systems, this may have an implication on the mobile node's accounting

- Page 43, 3rd para: s/access link, receives/access link receives

- Page 54: s/a denial-of-service attacks/a denial-of-service attack

- Page 55: s/different domains/different administrative domains

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Sep 2007 13:22:15 -0700

Hi Vidya,

I am responding to the major comments you have.

> Technical - Major: 

I don't think we should open the terminology issue again. We had 
extensive discussions on this in the past and concluded on the current 
terms. As long as the terminology section clearly describes what each 
term means, it should be fine.

> requirement being a unique identity that can be stable within the PMIP

That is correct. We do all allow other forms of the identities. We are 
using the option defined in RFC 4283. In this option, the sub-type when 
set to 1, indicates that it is the NAI. Other sub-types would be used to 
identify other identities.

> unauthorized PBU?  I would imagine that unauthorized PBUs are better

Are you talking about the "MAG_NOT_AUTHORIZED_FOR_PROXY_REG" error code? 
It can be argued that sending error codes is better than silently 
dropping messages for debugging purposes.

> such text.  Did I miss it? 

The conclusion from that thread was the multi-homing is out of scope for 
the base PMIPv6 spec and not supported in the base PMIPv6 document. I 
had proposed some text at that time. We never concluded on that.

> And, why is the source address relevant for a de-registration alone and

The emphasis is on ignore the de-registration proxy BU or responding to 
the old MAG with status 0. It was added to address one specific case - 
if the de-registration proxy BU from the old MAG is received after the 
proxy BU from the new MAG, the LMA is supposed to ignore the 
de-registration BU (but still respond to the old MAG with status 0).

I read the text, perhaps it would better to say the LMA always responds 
to the deregistration proxy BU (without deleting the binding cache 
entry). Not ignore it. If the LMA ignores it, the old MAG would only 
re-transmit the deregistration proxy BU.

> interval needs to be better defined. 

This was added to make sure the LMA does not release the home 
address/home network prefix for the mobile node during handovers. Lets 
say the old MAG has already de-registered, but the Proxy BU from the new 
MAG has not reached the LMA yet. If the LMA deletes the binding cache 
entry it might result in release of the home address/home network 
prefix. This was discussed on the mailing list.

> Why is it needed? 

To match the proxy Binding Ack to the proxy BU. The MAG could be sending 
proxy BUs for quite a few mobile nodes.

> it?  That seems to be one way of obtaining the LMA address, but, there

We don't mandate a policy profile. If a policy profile is used, then we 
say what needs to go into it and mandate that the MAG and the LMA should 
have access to it.

> that information specified as normative for implementation purposes. 

There are two pieces of information that the MAG needs to figure out. 
Prefix lifetime and the flags that indicate auto-configuration/DHCPv6. 
For the prefix lifetime, it would be MAG implementation specific. The 
MAG would know whether auto-configuration or DHCPv6 is being used. So it 
can set the flags accordingly.

Sri, please correct me if I am wrong.

> the MUSTs in this bullet. 

I agree, we need to fix the text here. The intention was not to mandate 
the MAG to authenticate the MN all the time. But the MAG must acquire 
the identifier somehow. It needs to include the identifier in the proxy BU.

> general, this is better to handle DoS attacks too. 

Lets follow up on that thread for this issue.

> already a plan to elaborate on the role of the MAG as a relay agent.

Any suggestions on improving it?  :)  I thought it is quite detailed. It 
was based on the discussions we have had so far on the use of DHCPv6.

> deregistered while it is in idle mode, for instance. 

I agree. The last bullet should be removed.

> defined PMIPv6 domain and the corresponding MN-HoA belonging to that

Agreed. Any text? Otherwise I will come up with some text.

> normative here, but, the security considerations as written is hand

We went back and forth on this. Some folks wanted to add hints to 
specific mechanisms and others wanted to leave this out of scope. The 
LMA checking with the AAA to see if the MN is attached to the MAG is a 
solution. But this relies on the AAA infrastructure being used. I think 
this is best left for other documents. Any suggestions on what "detail" 
we can add?

Vijay

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Sep 2007 15:34:28 -0500

One comment below.

> Subject: Re: [netlmm] Review of draft-ietf-netlmm-proxymip6-05
> 
> Hi Vidya,
> 
> > MN is called an MN in the MIP6 case, tagging "MN" before the HoA is 
> > not making it any more descriptive to the PMIP6 use.  I've 
> stated my 
> I don't think we should open the terminology issue again. We 
> had extensive discussions on this in the past and concluded 
> on the current terms. As long as the terminology section 
> clearly describes what each term means, it should be fine.

[Ahmad]
I second this. 
I may also add that people already got used to these terminology and we
should not try to open this again.

Regards,
Ahmad

> 
> > - MN Identifier: 
> > 
> > Page 15 (and other parts of the document) talks about 
> getting the MN 
> > ID from the NAI option.  Isn't NAI just one allowed type of 
> identity?  
> > A particular deployment may use other types of identities, the only 
> That is correct. We do all allow other forms of the 
> identities. We are using the option defined in RFC 4283. In 
> this option, the sub-type when set to 1, indicates that it is 
> the NAI. Other sub-types would be used to identify other identities.
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Sep 2007 17:21:34 -0500

Hi Vidya,

Please find one comment below.

Regards,
Ahmad

> Why is it needed?

[Ahmad]
There is a very good reason to have NAI in the P-BA.

In case that we have SQN used for ordering the P-BU/P-BA, there is a
great possibility of SQN collision. In this case, MAG needs the NAI to
match the P-BA to the outstanding P-BU.

Regards,
Ahmad

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 25 Sep 2007 17:48:05 -0500

Hi Vidya,

Please find one more comment below.

Regards,
Ahmad

> It is fine to have the method of authorizing a MAG be out of 
> scope for the specification itself, but, I think we need to 
> give some hints on what that means in the security 
> considerations section.  For instance, it could be about that 
> particular MAG just having an IPsec SA with that LMA or it 
> could be something more like that MAG being part of the 
> defined PMIPv6 domain and the corresponding MN-HoA belonging 
> to that domain, etc.  
> 
> Similar comment to the one above.  I think we need a bit more 
> detail on ensuring the MN is "definitively attached" to the 
> MAG that sent the PBU.
> For instance, it could be a AAA check upon reception of a PBU 
> (the document alludes to this somewhere), it could be a CGA 
> signature of the MN carried from an secure RS, in the PBU 
> (this needs more thinking), etc.  Again, it is fine that this 
> document doesn't define anything normative here, but, the 
> security considerations as written is hand waving this point. 
> 

[Ahmad]
As long as this is already documented out-of-scope, I do not see a need
to go into the details of any solution. 

The issue here is how much is too much vs. too little. If the
functionality is out-of-scope, then there is no point of getting into
unnecessary details that does not describe a full deployable solution
anyway. IMO, it is more destructive, for example, to document a very
high level idea as a solution.

I am under the impression that all of us are for getting this base
PMIPv6 protocol moves to IESG as soon as possible. In order to spend our
time in defining out-of-scope functionalities, I would guess the authors
will still be busy publishing new revisions a year from today:-(

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 25 Sep 2007 18:35:21 -0700

Hi Vijay, 

> -----Original Message-----
> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, September 25, 2007 1:22 PM
> To: Narayanan, Vidya
> Cc: [email-masked]

I don't really want a prolonged discussion on this topic again.  All the
points have been made.  The only point I'll note is that we never really
had a conclusion or clear consensus.  There were several logical points
made on why the current terms are not appropriate or clear, but, no
conclusions. 

> the NAI. Other sub-types would be used to identify other identities.

I think the document just needs to be cleaned up on where it refers to
the NAI.  At the moment, it is misleading, since it uses the term "NAI
option" in multiple places and gives the impression that we are
referring to only an NAI as an MN ID.  

> It can be argued that sending error codes is better than 
> silently dropping messages for debugging purposes.
> 

It is true that error messages aid debugging.  However, the errors could
be locally logged for debugging purposes.  The problem with sending
these messages that you make the LMA an oracle for DoS attacks. 

> > context of regular IP nodes that are multihomed, we 
> discussed how it 
> > is problematic when the same prefix/address is allocated to 
> multiple 
> > that every distinct interface of an MN attached to the PMIP 
> domain has 
> > a different unique identity?  If so, that needs to be stated. IMO, 
> > that may not be practical, especially, if an NAI is used as 
> the MN ID.  
> > So, in those cases, we really need to ensure that the LMA is not 
> > allocating the same prefix to multiple interfaces of a 
> multihomed MN.  
> > I think an appropriate rewording of this sentence may be something 
> > like "the LMA MUST ensure the allocated prefix is not 
> already in use, 
> > i.e., there is no existing BCE for that prefix on the LMA".
> > 
> The conclusion from that thread was the multi-homing is out 
> of scope for the base PMIPv6 spec and not supported in the 
> base PMIPv6 document. I had proposed some text at that time. 
> We never concluded on that.
> 

This needs a conclusion.  I'll start a separate thread on this topic. 

> > And, why is the source address relevant for a de-registration alone 
> > and not for other PBUs?
> 
> The emphasis is on ignore the de-registration proxy BU or 
> responding to the old MAG with status 0. It was added to 
> address one specific case - if the de-registration proxy BU 
> from the old MAG is received after the proxy BU from the new 
> MAG, the LMA is supposed to ignore the de-registration BU 
> (but still respond to the old MAG with status 0).
> 
> I read the text, perhaps it would better to say the LMA 
> always responds to the deregistration proxy BU (without 
> deleting the binding cache entry). Not ignore it. If the LMA 
> ignores it, the old MAG would only re-transmit the 
> deregistration proxy BU.
> 

Okay. That revision sounds more appropriate. 

> > received by the LMA for that MN? If that is sent to the CoA in the 
> > BCE, that is of no use.  If that data is dropped, then, it is 
> > equivalent to not having a BCE for that MN.  So, I'm not 
> exactly sure 
> > what that timer is achieving, other than avoiding giving up the HNP 
> > too soon.  If that is the only intent, then, I'd word it as 
> such and 
> > not say that the BCE is active.  Otherwise, the processing of data 
> > packets during that interval needs to be better defined.
> 
> address/home network prefix for the mobile node during 
> handovers. Lets say the old MAG has already de-registered, 
> but the Proxy BU from the new MAG has not reached the LMA 
> yet. If the LMA deletes the binding cache entry it might 
> result in release of the home address/home network prefix. 
> This was discussed on the mailing list.
> 

Yes, I think my paragraph captured this part.  The point I'm making is
that you are really trying to avoid releasing the HNP and not really
keeping the binding active when this timer is running.  If the binding
was active, you'd need to describe what happens to data packets
sent/received from/to the MN during that time interval.  I'd say that
the binding isn't available and hence, data will be dropped, but, the
HNP is not immediately released.  

> > - NAI option in the PBA: 
> > 
> > Why is it needed? 
> 
> To match the proxy Binding Ack to the proxy BU. The MAG could 
> be sending proxy BUs for quite a few mobile nodes.
> 

The sequence number and timestamp are both indicated as providing this
matching capability.  I don't think we need a third mechanism.  In fact,
I was going to include a comment that says we need to pick one to match
requests and responses - and that could easily be the sequence number
(treated as a message ID in this case). 

> > I'm not sure why this is mandatory.  For e.g., if a network has a 
> > policy to dynamically acquire an identity for the MN and assign an 
> > available HNP to that MN, it is not tied to "policy" in any way.  
> > Also, when a policy profile is present, why is the LMA address a 
> > mandatory field in it?  That seems to be one way of 
> obtaining the LMA 
> > address, but, there can be other ways.
> 
> We don't mandate a policy profile. If a policy profile is 
> used, then we say what needs to go into it and mandate that 
> the MAG and the LMA should have access to it.
> 

The text doesn't seem to read that way, at least to me. 

> > How does the MAG obtain the parameters other than the prefix needed 
> > for the RA? For instance, the flags or other options that 
> need to be sent?
> > Section 6.4 vaguely mentions based on policy, but, I don't 
> think that 
> > is good enough.  I think we need to have at least one mode of 
> > obtaining that information specified as normative for 
> implementation purposes.
> 
> For the prefix lifetime, it would be MAG implementation 
> specific. The MAG would know whether auto-configuration or 
> DHCPv6 is being used. So it can set the flags accordingly.
> 

Yes, the M and O flags are part of the information and so is the prefix
lifetime.  But, is there a default router lifetime option?  Any other
option that may need to be sent in the RA?  In general, I think it would
be good to describe how the MAG knows this stuff. 

> > system (presumably with or without some access authentication), it 
> > must use that identity for PMIP6.  Other than that, I don't quite 
> > understand the MUSTs in this bullet.
> 
> I agree, we need to fix the text here. The intention was not 
> to mandate the MAG to authenticate the MN all the time. But 
> the MAG must acquire the identifier somehow. It needs to 
> include the identifier in the proxy BU.
> 

Okay. 

> > must be provided by any other authentication mechanism in use).  
> > Having said that, it is typically easier for retransmissions to not 
> > have to alter the packet being sent.  Plus, that will help 
> the LMA be 
> > idempotent and just respond with the previously sent PBA 
> (if there was 
> > one).  In general, this is better to handle DoS attacks too.
> 
> Any suggestions on improving it?  :)  I thought it is quite 
> detailed. It was based on the discussions we have had so far 
> on the use of DHCPv6.
> 

At least the 05 version of the draft had 2 sentences on DHCP Relay
Agents and made no mention of the MAG's role in it.  Perhaps the 06
version has more detail?  

> I agree. The last bullet should be removed.

Okay. 

> > it could be about that particular MAG just having an IPsec SA with 
> > that LMA or it could be something more like that MAG being 
> part of the 

Please suggest text :) 

> > Similar comment to the one above.  I think we need a bit 
> more detail 
> > on ensuring the MN is "definitively attached" to the MAG 
> that sent the PBU.
> > document alludes to this somewhere), it could be a CGA signature of 
> > the MN carried from an secure RS, in the PBU (this needs more 
> > thinking), etc.  Again, it is fine that this document 
> doesn't define 
> > anything normative here, but, the security considerations 
> as written 
> > is hand waving this point.
> 
> We went back and forth on this. Some folks wanted to add 
> hints to specific mechanisms and others wanted to leave this 
> out of scope. The LMA checking with the AAA to see if the MN 
> is attached to the MAG is a solution. But this relies on the 
> AAA infrastructure being used. I think this is best left for 
> other documents. Any suggestions on what "detail" 
> we can add?
> 

If we claim this is an issue in the security considerations section and
claim that the fix to it is for the LMA to ensure the MN is actually
attached to the MAG, we can't quite hand wave on some possible ways to
do that.  Those are just hints for deployments that are concerned about
MAG compromise.  But, those hints need to be captured in the security
considerations section.  The threats document captures this threat and
it is a valid one - so, I believe we need some text here.  The type of
"detail" is what I tried to provide with the examples on AAA checks or
CGA signatures - and, I don't think we need a lot of detail here; a few
sentences would be good. 

Thanks,
Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 25 Sep 2007 18:38:25 -0700

Hi Ahmad, 

> In case that we have SQN used for ordering the P-BU/P-BA, 
> there is a great possibility of SQN collision. In this case, 
> MAG needs the NAI to match the P-BA to the outstanding P-BU.
> 

Hmmm.. In this case, I can see the use in including the MN ID in the
first PBA, but, subsequently, the HNP should be sufficient to match it
to the MN in the PBU and PBA, right? 

Vidya

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 25 Sep 2007 19:11:44 -0700

Hi Vidya,

Please see inline ...

Sri 

> made on why the current terms are not appropriate or clear, but, no

This terminology is there since -00 version of the WG doc. There
are no open issues on this topic and there are zero comments on
this. The same terminology is adopted by the other documents as
well, including the IPv4 support document. I think, we will never
converge on this, if we reopen this discussion.

> referring to only an NAI as an MN ID.  

Document refers to MN-Identifier in all places. However, the semantics
for carrying this identifier is based on NAI Option [4283]. This option
uses the identity construct from 4282. So, in the signaling considerations,
the spec talks about NAI option, from where the MN-Identifier is derived.
How else, we carry the MN-Identity across the mobility entities ?

> these messages that you make the LMA an oracle for DoS attacks. 

   MAG_NOT_AUTHORIZED_FOR_PROXY_REG:

This is not just for debugging. If a given MAG is not authorized
to send PBU's, the LMA has to gracefully notify that. This cannot
lead to dos attack. Not that there is a security relation between
this node and the LMA. Else, the PBU will be ignored.

> This needs a conclusion.  I'll start a separate thread on this topic. 

I think the conclusion was to disallow this. But, if you think
there are folks in the WG who are not happy with this conclusion,
you can start a thread, but, I'm not sure, if thats the case.

> HNP is not immediately released.  

Sure. As Pete pointed out, I need to provide guidance related to
routing during that wait period. This is a good comment.

> > be sending proxy BUs for quite a few mobile nodes.

Adding to Ahmad's comment.

Additionally, in a proxy model where the third party node is a
sender, the identity of the mobile is required in the messages.

> (treated as a message ID in this case). 

No. We still allow 3775 based sequence number support, which is
per mobile node basis. So, there could be a collision in seq
numbers at the MAG and so its not the definitive identifier.
So, we need to carry the NAI in PBA as well.

> The text doesn't seem to read that way, at least to me. 

Ok. Will clarify if it, if that's the case.

> be good to describe how the MAG knows this stuff. 

This is captured in Home Network Emulation section. See -06.txt
and let me know if it does not reflect that. I will make it
more clear. 

> Agents and made no mention of the MAG's role in it.  Perhaps the 06

Please see -06.txt

> CGA signatures - and, I don't think we need a lot of detail 

The threats document should cover this. I do not think, we can
mandate a specific method. I'm not sure, if this document will
add any value if we venture into this aspect. 

Thanks for the review.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 25 Sep 2007 19:13:50 -0700

> made on why the current terms are not appropriate or clear, but, no

I suggest we don't open up that discussion again then.

> referring to only an NAI as an MN ID.  

True, we need to call it the MN-identifier option. Not the NAI option. 
Needs to be fixed throughout.

> these messages that you make the LMA an oracle for DoS attacks. 

I don't see any state being created. At any rate, the LMA could 
implement rate-limiting for the number of proxy BUs it handles from a 
particular IP address/domain/MAG/etc... Sending the error message I 
believe is beneficial.

> Okay. That revision sounds more appropriate. 

Ok, will fix this.

> HNP is not immediately released.  

Agreed.

> matching capability.  

The sequence number does not have to be included. If there is no context 
transfer mechanism between MAGs to transfer the correct sequence number 
to be used, it won't work. Timestamps are not sufficient, since the MAG 
could send more than one proxy BU for different mobile nodes in the same 
second.

> I don't think we need a third mechanism.  

You need the MN-identifier to match the proxy BAck to the proxy BU.

> The text doesn't seem to read that way, at least to me. 

Which text?

> lifetime.  But, is there a default router lifetime option?  

MAG is the default router. So MAGs sets this value.

> Any other

What are we missing?

> Agents and made no mention of the MAG's role in it.  Perhaps the 06

See version 06, section 6.11

> CGA signatures - and, I don't think we need a lot of detail here; a few

Please provide text. :)

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 25 Sep 2007 19:30:01 -0700

> How else, we carry the MN-Identity across the mobility entities ?

There is a mistake on my part. I referred to the MN-Identifier
Option in 4283 as "NAI Option". Vijay pointed this out offline.
That is the cause for the confusion. Will change this. But, the
identifier carried in this option is still a construct as per
4282 and the option is still from 4283. My mistake. Will fix
this. 

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 25 Sep 2007 20:36:00 -0700

Vidya,

Responding to your other comments.. 

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Tuesday, September 25, 2007 1:42 AM
> To: [email-masked]
> Subject: [netlmm] Review of draft-ietf-netlmm-proxymip6-05
> 
> All,

This was discussed in the thread 
http://www1.ietf.org/mail-archive/web/netlmm/current/msg02383.html

The definition was discussed in the WG and adopted from
there. I can try to add the IP address part.

> text to the IPv4 document. 

This document does not explain how IPv4 transport or addressing
is achieved. It just points to the other document, to specify
the scope of this work. The references to IPv4 are only for
completeness. The IPv4 support doc is an extension to this work.

> think some more clarity there will be helpful.  

Will slightly reword it.

> packet as a PBU, based on the P flag? 

It starts with,
"Upon receiving a Proxy Binding Update request ...", so the
scope of that section is for that BU's with the "P" flag.

Any case, I will add a comment.

> packet MUST be used for locating..."

ok

> present in subsequent BUs.

Discussion on MN-Id is in the other thread.

> here.  For interoperability, I believe we should specify the range for

This was the comment from Shyam. It really depends on the mechanism
that is used for time synchronization and the accuracy provided by
that mechanism. Its better we leave this to deployments.

> not from a PMIP perspective. 

Is that inline with IETF security requirements for protocols ?
We put a MUST for network node security and a MAY for access
security ? I understand, in some networks this may not be 
enabled. But, the spec should require it.

> any identifier that uniquely identifies the MN in that domain. 

This is per 4282. What we carry is the MN-Identifier option
and we are bound to that definition in that option.

> of the network, it should be feasible.  Or, am I missing something? 

There were like million emails on this and that was the conclusion.
Kilian and Federico can explain it. You can look for the email threads
over the last 1 month.

> time out.  It seems like a SHOULD for de-registration is sufficient. 

What if the lifetime is very high and the mobile roams out of the
PMIP domain. It needs to clean up the visitor state.

> can be achieved by doing Y" would be more appropriate.  

hmm .. ok

> Editorial: 

Will fix the editorial comments. After Pete's thorough review,
not sure, how many are still there.

> referring to one such agent here. 

The protocol is a "proxy" based protocol.

> 6.8 and even there, it is a bit buried. 

ok

> additional considerations apply and leaving the "one 

ok

> use in regular expression.  Please note that "must" is equivalent to

Good point.

> document. The section currently only says RR cannot be used. 

But, we support local routing on the MAG. So, we strictly cant
say we dont support RO. We dont support RR as per 3775. RO is
a overloaded term.

> - RFC2461/2462 references should change to 2461bis and 2462bis

yep .. as Suresh pointed out.

> - Page 55: s/different domains/different administrative domains

Thanks for the review

Sri

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 26 Sep 2007 10:56:41 +0200

> > > - Security considerations: MAG Compromise: 
...
> CGA signatures - and, I don't think we need a lot of detail 

I had a similar comment a while ago. I think that a draft describing a
severe security issue should at least give hints how this can be solved.

Recently Sri, Vijay, Kuntal and I had an offline discussion about
another possible solution to detect a compromised MAGs, which relies on
PMIP signaling only.

The basic idea is that if two MAGs simultaneously claim that the MN is
attached, one of the MAGs must lie and is probably a compromised MAG.
The assumption is that the MN cannot at the same time be attached to two
MAGs, at least not with the same network interface.

More specifically, when the LMA accepts a valid PBU from a new MAG, it
changes the BCE (i.e., there is no impact on handover delay) and
notifies the old MAG (i.e., old address in BCE) about this. The old MAG
then checks whether the MN is still attached. If this is the case, it
informs the LMA about this. The LMA then learns that two different MAGs
claim MN attachement, which is not possible under the assumption stated
above. Hence, after receiving one or more such notifications, the LMA
can identify the compromised MAG and stop trusting this MAG.

A remaining problem was which message should be used to inform the old
MAG about the BCE change. PBA and revocation msg were discussed, but the
former is not sent unsolicited according to RFC3775 (which could be
overidden by PMIP spec of course) and the latter is not standardized
yet.

Comments?

Kilian

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 26 Sep 2007 08:02:55 -0500

Hi Kilian,
Please see comments below.

Regards,
Ahmad

> Subject: Compromised MAG issue (was [netlmm] Review of 
> draft-ietf-netlmm-proxymip6-05)
> 
> Narayanan, Vidya wrote:
> > If we claim this is an issue in the security considerations section 
> > and claim that the fix to it is for the LMA to ensure the MN is 
> > actually attached to the MAG, we can't quite hand wave on some 
> > possible ways to do that.  Those are just hints for 
> deployments that 
> > are concerned about MAG compromise.  But, those hints need to be 
> > captured in the security considerations section.  The 
> threats document 
> > captures this threat and it is a valid one - so, I believe we need 
> > some text here.  The type of "detail" is what I tried to 
> provide with 
> > the examples on AAA checks or CGA signatures - and, I don't 
> think we 
> > need a lot of detail here; a few sentences would be good.
> > 
> 

[Ahmad]
Hmmm. I guess that highlight the fact that binding revocation is
probably important for PMIPv6 base protocol deployment. I would
recommend that PMIPv6 base protocol continue to refer to this issue as
out-of-scope and:

1. Capture this scenario in the binding revocation draft under the
section related to PMIPv6 applicability.
2. Speed the process of addressing binding revocation by tagging it as
required for PMIPv6 deployment.
3. Kill 2 birds in one stone, PMIPv6 is advanced as per the plan to IESG
and speed up the adoption of binding revocation.

Does this sound a good plan?

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 26 Sep 2007 08:58:31 -0500

Hi Vidya,

Regards,
Ahmad

> Sent: Tuesday, September 25, 2007 8:38 PM
> To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
> Subject: RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05
> 
> Hi Ahmad, 
> 
> > > - NAI option in the PBA: 
> > > 
> > > Why is it needed?
> > 
> > [Ahmad]
> there is a 
> Hmmm.. In this case, I can see the use in including the MN ID 
> in the first PBA, but, subsequently, the HNP should be 
> sufficient to match it to the MN in the PBU and PBA, right? 

[Ahmad]
Technically; Yes I agree.

However, this message is not transmitted over the air, Are we concerned
about the size of the message here?
I guess including NAI in the initial P-BU and not in re-registration
P-BU adds some complexity to the MAG and probably a lot to the LMA. If
there is no real concern about including the NAI, I would recommend
keeping it unless there a serious advantage in making such
recommendation.

---

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

> overidden by PMIP spec of course) and the latter is not standardized

As I said in another threat, we really need to standardize the 
revocation message from the LMA to the old MAG ASAP.

Vijay

---

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

> revocation message from the LMA to the old MAG ASAP.

sorry, I meant "thread".

Vijay

---

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

Sri,
 
> there. I can try to add the IP address part.

Thanks. I recall the discussion, but, it still seems to make sense to
mention the part about unchanging IP address, since that is the
observable characteristic useful to the MN ultimately. 

> > - General: 
> > 
> > Parts of the document contains text on IPv4.  I suggest leaving the 
> > IPv4 text to the IPv4 document.
> >
> 
> This document does not explain how IPv4 transport or 
> addressing is achieved. It just points to the other document, 
> to specify the scope of this work. The references to IPv4 are 
> only for completeness. The IPv4 support doc is an extension 
> to this work.
> 

I realize that.  I think this text is going to raise unnecessary
questions outside the WG and as I see it, the text isn't adding a lot of
value.  That is why I'm suggesting to remove it. 

<snip>

> > enough" of the LMA's clock - I don't think "close enough" is 
> > sufficient here.  For interoperability, I believe we should specify 
> > the range for closeness.
> > 
> 

I'm not sure that this can be left to deployment.  This is not something
that is good to be configurable - hence, this may be an implementation
choice and not a deployment choice.  If it is an implementation choice,
something needs to be specified as a mandatory behavior.  Otherwise, the
MAG and LMA may have different ranges and that would be a problem.
Knowing the accuracy and adjusting for some transmission delays, I think
we can come up with a reasonable number - I think it was 8 seconds in
MIP4? 

> Is that inline with IETF security requirements for protocols ?

First, there is no such thing as IETF security "requirements" - there
are guidelines.  But, those only apply to the protocol being specified.
In this case, access authentication has absolutely nothing to do with
PMIP6 (which is what this document is specifying) whatsoever.  The MN
accesses the system however it was allowed to access it, period.  So,
having text on access authentication in the PMIP6 specification is not
making sense to me. 

> enabled. But, the spec should require it.

No, please see above explanation. 

> and we are bound to that definition in that option.

Actually, we are using RFC4283.  The only sub-type defined there is the
RFC4282-based NAI option.  However, if someone defined additional
subtypes, it may be different from an NAI.  We don't need to be bound to
the only currently defined subtype.  At least, we should be mindful that
there may be other types. 

> PMIP domain. It needs to clean up the visitor state.

I'm not sure I understand.  If a system gives out really long lifetimes,
it probably should have de-registration capabilities.  But, if not, the
soft state operation of the protocol is enough.  Actually, in some
systems, there may be notifications between MAGs so that the old MAG
knows that another MAG has taken over.  So, I really think SHOULD is
more than sufficient - it is clearly not a MUST. 

Thanks,
Vidya

---

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

A few observations here. I don't believe binding revocation is going to
solve anything here.  The fundamental issue is how the LMA *identifies*
the compromised MAG, not how the compromised MAG is notified that its
binding is no longer valid.  Once the MAG is identified as compromised,
a number of remedies may be taken, including, simply blacklisting the
MAG and not accepting PBUs from it.  It is not critical that the binding
be revoked, because, the LMA has already identified where the MN really
is and it just needs to use that binding for data acceptance/forwarding.

The issue of how the LMA identifies a compromised MAG cannot be tackled
without an independent verification of the presence of the MN at that
particular MAG.  So, we need to focus on providing hints on how the LMA
may go about achieving that. 

Vidya

> Sent: Wednesday, September 26, 2007 11:08 AM
> To: Kilian Weniger
> Cc: Narayanan, Vidya; [email-masked]
> Subject: Re: Compromised MAG issue (was [netlmm] Review of 
> >> captured in the security considerations section.  The threats 
> >> document captures this threat and it is a valid one - so, 
> I believe 
> >> we need some text here.  The type of "detail" is what I tried to 
> >> provide with the examples on AAA checks or CGA signatures - and, I 
> >> don't think we need a lot of detail here; a few sentences would be 
> >> good.
> >>
> > 
> > another possible solution to detect a compromised MAGs, 
> which relies 
> > on PMIP signaling only.
> > 
> > The assumption is that the MN cannot at the same time be 
> attached to 
> > two MAGs, at least not with the same network interface.
> > 
> > notifies the old MAG (i.e., old address in BCE) about this. The old 
> > MAG then checks whether the MN is still attached. If this 
> is the case, 
> > it informs the LMA about this. The LMA then learns that two 
> different 
> > MAGs claim MN attachement, which is not possible under the 
> assumption 
> > stated above. Hence, after receiving one or more such 
> notifications, 
> > the LMA can identify the compromised MAG and stop trusting this MAG.
> > 
> > MAG about the BCE change. PBA and revocation msg were 
> discussed, but 
> > the former is not sent unsolicited according to RFC3775 
> (which could 
> > be overidden by PMIP spec of course) and the latter is not 
> > standardized yet.
> 
> As I said in another threat, we really need to standardize 
> the revocation message from the LMA to the old MAG ASAP.
> 
> Vijay
>

---

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

> is and it just needs to use that binding for data acceptance/forwarding.

There is an issue of LMA identifying a compromised MAG. That is true. 
But that issue has been complicated by having to deal with receiving 
out-of-order proxy BUs from legitimate MAGs. So the registration 
revocation mechanism is one component of the solution.

> may go about achieving that. 

Well, one option is for the LMA to check with the AAA server if the MN 
is attached to the MAG currently. We can provide a hint to this. 
Anything else, for example the CGA stuff, would need substantial 
explanation on how it is supposed to work.

Vijay

---

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

Hi Vidya,

Using revocation for the compromised MAG was proposed by Kilian, et. al.
but I am trying to help closing the issue so please allow me to jump
into this debate.

In order for the LMA to validate the presence of the MN at a specific
MAG, the LMA needs to do one of the followings:

1. Validate the MN identity via a MN signature carried in the P-BU. In
P-MIPv6 this currently is not available since the P-BU is NOT initiated
by the MN. (the most obvious option)

2. Validate the MN presence via another trusted entity that *ALWAYS*
tracks the MN current location, e.g. AAA server.

3. Validate the MN presence via another trusted entity that tracks the
current or latest location of the MN, e.g. the previous MAG using
binding revocation as was suggested by kilian et. al.

4. may be there are other ways...

In case that the MN is still at pMAG and has not moved, the pMAG can
easily indicate that in the binding revocation acknowledgement.

So do not you think that should work?

Regards,
Ahmad

> Sent: Wednesday, September 26, 2007 3:49 PM
> To: Vijay Devarapalli; Kilian Weniger
> Cc: [email-masked]
> Subject: RE: Compromised MAG issue (was [netlmm] Review of 
> A few observations here. I don't believe binding revocation 
> is going to solve anything here.  The fundamental issue is 
> how the LMA *identifies* the compromised MAG, not how the 
> compromised MAG is notified that its binding is no longer 
> valid.  Once the MAG is identified as compromised, a number 
> of remedies may be taken, including, simply blacklisting the 
> MAG and not accepting PBUs from it.  It is not critical that 
> the binding be revoked, because, the LMA has already 
> identified where the MN really is and it just needs to use 
> that binding for data acceptance/forwarding.
> 
> 
> The issue of how the LMA identifies a compromised MAG cannot 
> be tackled without an independent verification of the 
> presence of the MN at that particular MAG.  So, we need to 
> focus on providing hints on how the LMA may go about achieving that. 
> 
> Vidya
>

---

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

> Sent: Wednesday, September 26, 2007 2:30 PM
> To: Narayanan, Vidya
> Cc: Kilian Weniger; [email-masked]
> is going 
> > to solve anything here.  The fundamental issue is how the LMA 
> > *identifies* the compromised MAG, not how the compromised MAG is 
> > notified that its binding is no longer valid.  Once the MAG is 
> > identified as compromised, a number of remedies may be taken, 
> > including, simply blacklisting the MAG and not accepting 
> PBUs from it.  
> > It is not critical that the binding be revoked, because, 
> the LMA has 
> > already identified where the MN really is and it just needs 
> to use that binding for data acceptance/forwarding.
> 
> But that issue has been complicated by having to deal with 
> receiving out-of-order proxy BUs from legitimate MAGs. So the 
> registration revocation mechanism is one component of the solution.
> 

Sorry, I don't understand the issue with out-of-order PBUs - could you
please elaborate on it? 

Vidya

> > The issue of how the LMA identifies a compromised MAG cannot be 
> > tackled without an independent verification of the presence 
> of the MN 
> > at that particular MAG.  So, we need to focus on providing hints on 
> > how the LMA may go about achieving that.
> 
> Well, one option is for the LMA to check with the AAA server 
> if the MN is attached to the MAG currently. We can provide a 
> hint to this. 
> Anything else, for example the CGA stuff, would need 
> substantial explanation on how it is supposed to work.
> 
> Vijay
> 
> > 
> > Vidya
> >

---

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

Hi Ahmad,

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Wednesday, September 26, 2007 4:12 PM
> To: Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger
> Cc: [email-masked]
> but I am trying to help closing the issue so please allow me 
> to jump into this debate.
> 
> In order for the LMA to validate the presence of the MN at a 
> specific MAG, the LMA needs to do one of the followings:
> 
> P-MIPv6 this currently is not available since the P-BU is NOT 
> initiated by the MN. (the most obvious option)
> 
> 2. Validate the MN presence via another trusted entity that 
> *ALWAYS* tracks the MN current location, e.g. AAA server.
> 
> 3. Validate the MN presence via another trusted entity that 
> tracks the current or latest location of the MN, e.g. the 
> previous MAG using binding revocation as was suggested by 
> kilian et. al.
> 

The LMA can't assume that the pMAG is trusted while the new MAG is the
one lying.  Perhaps the MN really moved and the pMAG continues to claim
it is there.  Regardless of which MAG tells the LMA what, 1 or 2 needs
to occur to conclude where the MN really is and then, the LMA can
determine which of the MAGs was lying. 

Regards,
Vidya

> In case that the MN is still at pMAG and has not moved, the 
> pMAG can easily indicate that in the binding revocation 
> acknowledgement.
> 
> > already identified where the MN really is and it just needs to use

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Thu, 27 Sep 2007 20:01:09 +0200

Hi Killian,

I had been told that this problem was out of scope ...
>From your input:
Killian> Hence, after receiving one or more such notifications, the LMA can identify the compromised MAG and stop trusting this MAG.
How does the LMA identify the compromised MAG?

Regards

federico

-----Message d'origine-----
De : Kilian Weniger [mailto:[email-masked]] 
Envoyé : mercredi 26 septembre 2007 10:57
À : Narayanan, Vidya
Cc : [email-masked]
Objet : Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)

...
> possible ways to do that.  Those are just hints for deployments that 
> captured in the security considerations section.  The threats document 
> some text here.  The type of "detail" is what I tried to provide with 
> the examples on AAA checks or CGA signatures - and, I don't think we 

Comments?

Kilian

---

From: "Kilian Weniger" <[email-masked]>
Date: Fri, 28 Sep 2007 14:11:08 +0200

Hi Frederico, 

one way to identify a compromised MAG is to rely on notifications from multiple MAGs and trust the opinion of the majority: If the LMA detects the situation that two MAGs simultaneously claim attachment of same MN multiple times and one of the MAGs is always MAG X while the other one is different each time, the LMA can be pretty sure that MAG X is the compromised MAG.

BR,

Kilian

> From: DE JUAN HUARTE FEDERICO 
> [mailto:[email-masked]] 
> Sent: Donnerstag, 27. September 2007 20:01
> To: Kilian Weniger
> Cc: [email-masked]
> Subject: RE: Compromised MAG issue (was [netlmm] Review 
> ofdraft-ietf-netlmm-proxymip6-05)
> 
> Hi Killian,
> 
> Killian> Hence, after receiving one or more such 
> notifications, the LMA can identify the compromised MAG and 
> stop trusting this MAG.
> attached to two
> discussed, but the

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 15:44:05 +0200

eventually go stale
Is the MAG LLA actually relevant for the host?

Regards

federico

-----Message d'origine-----
De : Sri Gundavelli [mailto:[email-masked]] 
Envoyé : jeudi 27 septembre 2007 19:41
À : 'Basavaraj Patil'; 'Julien Laganier'; [email-masked]
Objet : RE: Default router and new MAG (Was: [netlmm] Suresh's reviewofdraft-ietf-netlmm-proxymip6-05)

Raj, 

> > 
> > Thanks. This is very important. I can add a reference to this.
> > Probably, a good reason to enable to DNAv6 on the MN.
> 
> We cannot be having any requirements on the MN. So lets not start 
> saying that the MN should enable DNAv6 or expect it to do anything new 
> for it to work in a PMIP domain.
> 

We are not mandating DNAv6. Its informational. If MN has DNAv6 stack, it can flush the old AR entry immediatly. That is very important. Do you see any issue, stating that point ? 

Sri

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 15:44:05 +0200

Hi Ahmead

Please see inline
Regards

federico 

-----Message d'origine-----
De : Ahmad Muhanna [mailto:[email-masked]] 
Envoyé : jeudi 27 septembre 2007 01:12
À : Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger
Cc : [email-masked]
Objet : RE: Compromised MAG issue (was [netlmm]Review of draft-ietf-netlmm-proxymip6-05)

Hi Vidya,

Using revocation for the compromised MAG was proposed by Kilian, et. al.
but I am trying to help closing the issue so please allow me to jump into this debate.

In order for the LMA to validate the presence of the MN at a specific MAG, the LMA needs to do one of the followings:

1. Validate the MN identity via a MN signature carried in the P-BU. In
P-MIPv6 this currently is not available since the P-BU is NOT initiated by the MN. (the most obvious option)
[FDJ] Adding a MN-signature does not require that the BU is initiated by the MAG, does it?

2. Validate the MN presence via another trusted entity that *ALWAYS* tracks the MN current location, e.g. AAA server.

3. Validate the MN presence via another trusted entity that tracks the current or latest location of the MN, e.g. the previous MAG using binding revocation as was suggested by kilian et. al.
[FDJ] Apart form Vidya's comment, this bullet also misses the initial registration (no previous MAG available)

In case that the MN is still at pMAG and has not moved, the pMAG can easily indicate that in the binding revocation acknowledgement.

Regards,
Ahmad

> A few observations here. I don't believe binding revocation is going 
> including, simply blacklisting the MAG and not accepting PBUs from it.  
> It is not critical that the binding be revoked, because, the LMA has 
> >rg/pipermail/netlmm>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/netlmm>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

Hi Ahmead

Please see inline
Regards

federico 

-----Message d'origine-----
De : Ahmad Muhanna [mailto:[email-masked]] 
Envoyé : jeudi 27 septembre 2007 01:12
À : Narayanan, Vidya; Vijay Devarapalli; Kilian Weniger
Cc : [email-masked]
Objet : RE: Compromised MAG issue (was [netlmm]Review of draft-ietf-netlmm-proxymip6-05)

Hi Vidya,

Using revocation for the compromised MAG was proposed by Kilian, et. al.
but I am trying to help closing the issue so please allow me to jump into this debate.

In order for the LMA to validate the presence of the MN at a specific MAG, the LMA needs to do one of the followings:

1. Validate the MN identity via a MN signature carried in the P-BU. In
P-MIPv6 this currently is not available since the P-BU is NOT initiated by the MN. (the most obvious option)
[FDJ] Adding a MN-signature does not require that the BU is initiated by the MAG, does it?

2. Validate the MN presence via another trusted entity that *ALWAYS* tracks the MN current location, e.g. AAA server.

3. Validate the MN presence via another trusted entity that tracks the current or latest location of the MN, e.g. the previous MAG using binding revocation as was suggested by kilian et. al.
[FDJ] Apart form Vidya's comment, this bullet also misses the initial registration (no previous MAG available)

In case that the MN is still at pMAG and has not moved, the pMAG can easily indicate that in the binding revocation acknowledgement.

Regards,
Ahmad

> A few observations here. I don't believe binding revocation is going 
> including, simply blacklisting the MAG and not accepting PBUs from it.  
> It is not critical that the binding be revoked, because, the LMA has

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 28 Sep 2007 08:48:22 -0500

Hi Federico,

Let us focus on the proposed text and close this thread.
We all agree that a detailed solution is out-of-scope.

Thanks. 

Regards,
Ahmad

> Sent: Friday, September 28, 2007 8:44 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: RE: Compromised MAG issue (was [netlmm]Review of 
> De : Ahmad Muhanna [mailto:[email-masked]] Envoyé : 
> jeudi 27 septembre 2007 01:12 À : Narayanan, Vidya; Vijay 
> Devarapalli; Kilian Weniger Cc : [email-masked] Objet : RE: 
> Compromised MAG issue (was [netlmm]Review of 
> initiated by the MN. (the most obvious option) [FDJ] Adding a 
> MN-signature does not require that the BU is initiated by the 
> MAG, does it?
> 
> [FDJ] Apart form Vidya's comment, this bullet also misses the 
> initial registration (no previous MAG available)
>

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 17:30:46 +0200

Hi Killian,

a couple quick comments about the solution you propose:
   - it limits the impact but it doesn't avoid it completely: for a period of time the network is compromised
   - it can not be generalized to solve the problem when the number of compromised MAGs is more than one

Regards

federico

-----Message d'origine-----
De : Kilian Weniger [mailto:[email-masked]] 
Envoyé : vendredi 28 septembre 2007 14:11
À : DE JUAN HUARTE FEDERICO
Cc : [email-masked]
Objet : RE: Compromised MAG issue (was [netlmm] Review ofdraft-ietf-netlmm-proxymip6-05)

Hi Frederico, 

BR,

Kilian

> notifications, the LMA can identify the compromised MAG and stop 
> trusting this MAG.
> Envoyé : mercredi 26 septembre 2007 10:57 À : Narayanan, Vidya Cc : 
> [email-masked] Objet : Compromised MAG issue (was [netlmm] Review
> another possible solution to detect a compromised MAGs, which relies 
> on PMIP signaling only.
> 
> The assumption is that the MN cannot at the same time be attached to 
> informs the LMA about this. The LMA then learns that two different 
> MAGs claim MN attachement, which is not possible under the assumption 
> stated above. Hence, after receiving one or more such notifications, 
> MAG about the BCE change. PBA and revocation msg were discussed, but 
> the former is not sent unsolicited according to RFC3775 (which could

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 28 Sep 2007 18:36:22 +0200

Hi Ahmad,

catching up with this week emails ...
In the use case of SQNs, I presume that it is the SQN itself that would be used for matching PBU<=>PBA
Having both the SQN and the NAI in the PBA seems to me redundant
Then, the LMA doesn't need to add the NAI in any PBA

Regards

federico

-----Message d'origine-----
De : Ahmad Muhanna [mailto:[email-masked]] 
Envoyé : mercredi 26 septembre 2007 15:59
À : Narayanan, Vidya; [email-masked]
Objet : RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05

Hi Vidya,

Regards,
Ahmad

[Ahmad]

However, this message is not transmitted over the air, Are we concerned about the size of the message here?
I guess including NAI in the initial P-BU and not in re-registration P-BU adds some complexity to the MAG and probably a lot to the LMA. If there is no real concern about including the NAI, I would recommend keeping it unless there a serious advantage in making such recommendation.

---

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

Hi Federico,

No problem, do you we need to keep this thread open for another 2 weeks or so :-)

Of course SQN is used to map the P-BA to the outstanding P-BU. But there is a great possibility of collision. In that case we need the NAI.

BTW: I thought that we already converged on this very specific one.
Cheers.

Regards,
Ahmad

> Sent: Friday, September 28, 2007 11:36 AM
> Cc: [email-masked]; Narayanan, Vidya
> In the use case of SQNs, I presume that it is the SQN itself 
> that would be used for matching PBU<=>PBA Having both the SQN 
> and the NAI in the PBA seems to me redundant Then, the LMA 
> doesn't need to add the NAI in any PBA
> 
> Regards
> 
> federico
> 
> 
> mercredi 26 septembre 2007 15:59 À : Narayanan, Vidya; 
> [email-masked] Objet : RE: [netlmm] Review of 
> draft-ietf-netlmm-proxymip6-05
> 
> Hi Vidya,
> 
> Regards,
> Ahmad
>  
> 
> However, this message is not transmitted over the air, Are we 
> concerned about the size of the message here?
> I guess including NAI in the initial P-BU and not in 
> re-registration P-BU adds some complexity to the MAG and 
> probably a lot to the LMA. If there is no real concern about 
> including the NAI, I would recommend keeping it unless there 
> a serious advantage in making such recommendation.
> 
> 
> > 
> > Vidya
> > 
> > > Regards,
> > > Ahmad
> > > 
> > > > 
> > > 
> > 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Sep 2007 19:18:14 +0200

Ahmad Muhanna wrote:
> Of course SQN is used to map the P-BA to the outstanding P-BU. But
> there is a great possibility of collision. In that case we need the
> NAI.
> 

Ahmad, I don't converge on PMIP6 using exclusively the NAI to identify
the Mobile Node.  I think the protocol PMIP6 itself should work ok if it
identified the mobile by its IP address; and then use NAI if necessary
sometimes in some deployments.  But in no case should PMIP6 IMHO use NAI
to assign an address to the mobile: we already have many mechanisms for
that.

Alex

> 
> Regards, Ahmad
> 
> 
>> -----Original Message----- From: DE JUAN HUARTE FEDERICO 
>> [mailto:[email-masked]] Sent: Friday,
>> September 28, 2007 11:36 AM To: Muhanna, Ahmad (RICH1:2H10) Cc:
>> [email-masked]; Narayanan, Vidya Subject: RE: [netlmm] Review of
>> catching up with this week emails ... In the use case of SQNs, I
>> presume that it is the SQN itself that would be used for matching
>> PBU<=>PBA Having both the SQN and the NAI in the PBA seems to me
>> redundant Then, the LMA doesn't need to add the NAI in any PBA
>> 
>> Regards
>> 
>> federico
>> 
>> 
>> -----Message d'origine----- De : Ahmad Muhanna
>> [mailto:[email-masked]] Envoyé : mercredi 26 septembre 2007
>> 15:59 À : Narayanan, Vidya; [email-masked] Objet : RE: [netlmm]
>> Review of draft-ietf-netlmm-proxymip6-05
>> 
>> Hi Vidya,
>> 
>> Regards, Ahmad
>> 
>> 
>>> -----Original Message----- From: Narayanan, Vidya
>>> [mailto:[email-masked]] Sent: Tuesday, September 25, 2007
>>> 8:38 PM To: Muhanna, Ahmad (RICH1:2H10); [email-masked] Subject:
>>> RE: [netlmm] Review of draft-ietf-netlmm-proxymip6-05
>>> 
>>> Hi Ahmad,
>>> 
>>>>> - NAI option in the PBA:
>>>>> 
>>>>> Why is it needed?
>>>> [Ahmad] There is a very good reason to have NAI in the P-BA.
>>>> 
>> [Ahmad] Technically; Yes I agree.
>> 
>> concerned about the size of the message here? I guess including NAI
>> in the initial P-BU and not in re-registration P-BU adds some
>> complexity to the MAG and probably a lot to the LMA. If there is no
>> real concern about including the NAI, I would recommend keeping it
>> unless there a serious advantage in making such recommendation.
>> 
>> 
>>> Vidya
>>> 
>>>> Regards, Ahmad
>>>> 
>> _______________________________________________ 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 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: Fri, 28 Sep 2007 12:21:53 -0500

Alex,

But that is a different topic. We are talking about the need for NAI in case of SQN collision. I thought that we converged on that longtime ago. But what you are saying is something different. Right?

Regards,
Ahmad

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Friday, September 28, 2007 12:18 PM
> Cc: DE JUAN HUARTE FEDERICO; [email-masked]
> Ahmad, I don't converge on PMIP6 using exclusively the NAI to 
> identify the Mobile Node.  I think the protocol PMIP6 itself 
> should work ok if it identified the mobile by its IP address; 
> and then use NAI if necessary sometimes in some deployments.  
> But in no case should PMIP6 IMHO use NAI to assign an address 
> to the mobile: we already have many mechanisms for that.
> 
> Alex
> 
> > 
> > Regards, Ahmad
> > 
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Sep 2007 19:39:57 +0200

Ahmad Muhanna wrote:
> Alex,
> 
> But that is a different topic. We are talking about the need for NAI 
> in case of SQN collision. I thought that we converged on that 
> longtime ago. But what you are saying is something different. Right?

Right, it is different.  When/if there's SQN collision NAI or home
address can be able to solve the collision.

But to a certain extent we're talking long and wide about NAI and
identifiers and this stales the advancement.  If we kept PMIP6 without
NAI in the basic specification then we'd not even need to converge.

Alex

> 
> Regards, Ahmad
> 
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Friday, September 28, 
>> 2007 12:18 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: DE JUAN HUARTE 
>> FEDERICO; [email-masked] Subject: Re: [netlmm] Review of 
>>> Of course SQN is used to map the P-BA to the outstanding P-BU. 
>>> But there is a great possibility of collision. In that case we 
>>> need the NAI.
>>> 
>>> BTW: I thought that we already converged on this very specific 
>>> one. Cheers.
identify the Mobile Node.  I think the protocol PMIP6 itself should
>> work ok if it identified the mobile by its IP address; and then use
>>  NAI if necessary sometimes in some deployments. But in no case 
>> should PMIP6 IMHO use NAI to assign an address to the mobile: we 
>> already have many mechanisms for that.
>> 
>> Alex
>> 
>>> Regards, Ahmad
>>> 
>>> 
[mailto:[email-masked]] Sent:
>>>> Friday, September 28, 2007 11:36 AM To: Muhanna, Ahmad 
>>>> (RICH1:2H10) Cc: [email-masked]; Narayanan, Vidya Subject: RE:
>>>>  [netlmm] Review of draft-ietf-netlmm-proxymip6-05
>>>> 
>>>> Hi Ahmad,
>>>> 
>>>> catching up with this week emails ... In the use case of SQNs, 
>>>> I presume that it is the SQN itself that would be used for 
>>>> matching PBU<=>PBA Having both the SQN and the NAI in the PBA 
>>>> seems to me redundant Then, the LMA doesn't need to add the NAI
>>>>  in any PBA
>>>> 
>>>> Regards
>>>> 
>>>> federico
>>>> 
>>>> 
[mailto:[email-masked]] Envoyé : mercredi 26 septembre
>>>> 2007 15:59 À : Narayanan, Vidya; [email-masked] Objet : RE: 
>>>> [netlmm] Review of draft-ietf-netlmm-proxymip6-05
>>>> 
>>>> Hi Vidya,
>>>> 
>>>> Regards, Ahmad
>>>> 
>>>> 
[mailto:[email-masked]] Sent: Tuesday, September 25,
>>>>> 2007 8:38 PM To: Muhanna, Ahmad (RICH1:2H10); [email-masked]
>>>>>> great possibility of SQN collision. In this case, MAG needs
>>>>>> 
>>>>>> 
>>>>> the NAI to
concerned about the size of the message here? I guess
>> including NAI
complexity to the MAG and probably a lot to the LMA. If
>> there is no
>>>> real concern about including the NAI, I would recommend keeping
>>>>  it unless there a serious advantage in making such 
>>>> recommendation.
>>>> 
>>>> 
>>>>> Vidya
>>>>> 
>>>>>> Regards, Ahmad
>>>>>> 
>>> _______________________________________________ netlmm mailing 
>>> list [email-masked] 
>>  This email has been scanned by the MessageLabs Email Security 
>> System. For more information please visit
http://www.messagelabs.com/email
______________________________________________________________________