Subject: [Mipshop] Re: AD review of draft-ietf-mipshop-fmipv6-rfc4068bis

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Jan 2008 16:00:48 +0200

Continuing the discussion with this document....

>> Ok. But still, I think it would be beneficial to describe what
>> the other data structures are that you need. (At a conceptual
>> level.)
>>
>>     
>
> I will see how to keep this at a high level.
>   

Ok, good.

>>> It may, but that's not something this protocol explicitly supports. May be
>>> we could specify it for such devices in a different spec, if there is
>>> interest..
>>>   
>>>       
>> I don't think that is the way we should do this. Existing switches, router
>> behavior, ND, MLD snooping --- all of that should be taken as a given,
>> and you should generally be able to live with it, unless there is a
>> significant
>> reason to not to.
>>
>> The high level question in this case is who dictates the ND/DNA/DAD/MLD/etc
>> behaviour of the FMIP mobile node? This spec? Someone else?
>>
>> I would say that you should refer to other specifications where
>> possible. E.g.,
>> this specification does not change anything in the requirements of 4861
>> about what ND should do about new links. But where that is not the case,
>> you should deal with it.
>>
>>     
>
> Looks like having a section on "Implications" would be useful. 

Yes.

> I have
> perhaps taken for granted that the existing devices, other than the router
> and the MN, do not have to do anything. (This is supported by a few
> implementations). 
>   

Indeed, and that is the normal case. We still have to describe other
cases, such as those involving MLD snooping switches.

>>> The NCoA is looked up with the LLA (supplied in UNA) by the NAR. The same
>>> LLA is also supplied in the HI message. So, NAR recognizes that it belongs
>>> to the MN in question.
>>>   
>>>       
>> Hmm. How?
>>
>> Specifically, how does the NAR differentiate between (a) someone has the
>> same link layer address and just happened to send UNA and (b) the same
>> mobile node already moved here?
>>     
>
> An existing node on the link typically sends the UNA with O=1 when it wishes
> to update the LLA among the other nodes. MN can only send it with O=0.
> 2861/2461 both allow O=0, but see the discussion below.
>
>   
>> Or are you saying that you don't need to distinguish these from
>> each other? If yes, can you explain why?
>>
>>     
>>> Yes, the protocol is not assuming that all the node addresses will be in the
>>> cache. IF there is an entry, the NAR can detect it.
>>>   
>>>       
>> So this means that the protocol makes address allocation
>> decisions with an algorithm that has a failure mode where
>> it does not detect that an address was already in use?
>> Wouldn't this be bad?
>>
>>     
>
> Even if the address is not in NCE, the failure mode you are referring to is
> 1 in 2^64. 
>   

One mobile node against another one? What if there are many nodes, I
suspect the birthday paradox will mean that the likelihood of a
collision is larger.

In any case, I am not trying to argue that the likelihood of a collision
is large. But I am worried when a new Proposed Standard specification
makes something that normally works in IPv6 not work. In such a
situation, we normally try to either find a better solution, restrict
the scope of the new specification to a situation where the problem
cannot occur, etc.

> Nevertheless, the protocol clearly states that it SHOULD only be used where
> the probability of collision is extremely low.
>
> The protocol also allows for the scenario where conflict-free addresses are
> maintained (by techniques not specified by the protocol) by the router and
> handed out to the MNs.
>   

I think our first step needs to be that the document clearly states what
its capabilities are for duplicate address detection. Once we have that,
we can try to see whether reducing the scope or coming up with a better
solution is the right direction.

>> So, in conclusion, will you update the spec with regards to
>> what it does or does not differently from plain old ND?
>> (As defined in 4861.)
>>
>>     
>
> Ok.
>   

Good.

Jari

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

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Jan 2008 16:39:26 +0200

FYI -- I have looked a the new revision (-04). I'm generally
happy with the changes except for a few issues noted below.
I have not gone through my own original comments to see
if everything has been addressed. I will do so later today,
hopefully.

Section 7, related protocol considerations.

  The contents are good, but I'm uncertain if
  there are considerations that you have missed.
  Depending on what you specify the mobile node must
  do when it attaches to a new router, this may
  have implications for MLD snooping switches.
  (Unless, of course, you require all the usual
  steps to be taken at the ND/RD/MLD/DHCP level
  when you enter a new link, but that was unclear
  to me by reading the document).

Section 9, the router - router security.

  I do not recall the context of this change,
  but generally speaking you cannot leave
  mandatory-to-implement security mechanism
  out of your protocol.

Page 7, the dhcp instruction.

  It says:

     The information provided in the PrRtAdv message
     can be used even when DHCP [rfc3315] is used to
     configure an NCoA on the NAR's link. In this case,
     the protocol supports forwarding for PCoA and the MN
     performs DHCP once it attaches to the NAR's link
     even though it formulates an NCoA for transmitting FBU.

  This is good otherwise, but I don't understand the
  part about "even though". Do you intend to use the
  address before it is assigned by DHCP? This maybe
  problematic. In any case, please clarify.

Jari

---

From: <[email-masked]>
Date: Tue, 15 Jan 2008 17:18:32 +0000

Hello,
 
I have submitted a new draft related to FMIPv6 titled "Pro-active Bindings for FMIPv6" that deals will reducing the tunnel duration and hence preserve resources at PAR and NAR.
 
The draft is available under the following link:
http://tools.ietf.org/id/draft-yousaf-ietf-mipshop-pbfmipv6-00.txt
 
I would appreciate expert comments and critique on it.
 
Looking forward
 
Best Regards
 
Faqir Zarrar Yousaf
_________________________________________________________________
Make distant family not so distant with Windows Vista® + Windows Live™.
http://www.microsoft.com/windows/digitallife/keepintouch.mspx?ocid=TXT_TAGLM_CPC_VideoChat_distantfamily_012008

---

From: "Rajeev Koodli" <[email-masked]>
Date: Wed, 16 Jan 2008 10:57:33 -0800

Hi Jari,

>  to me by reading the document).

The additional requirement specified by this document is to send UNA as soon
as attachment to NAR is detected. Other than that, it does not impose any
other requirements. Hence, there are no implications as stated in Section 7.

>  mandatory-to-implement security mechanism

The context is that you agreed the protocol does not have to specify the
security configuration (I would have to dig out the e-mail). Agree that you
cannot leave mandatory parts. However, here we are assuming that the network
between the routers is secure (established by means beyond the scope of this
document).

>  problematic. In any case, please clarify.

No, NCoA is not used before DHCP grants address. Packet forwarding happens
using PCoA.
NCoA is used only in FBU following the usual semantics. This is explained
further in Section 6.1

"A Proxy Router Advertisement with Code 5 means that the MN may use the new
router information present for detecting movement to a new subnet, but the
MN must perform DHCP [rfc3315] upon attaching to the NAR's link. The PAR and
NAR will forward packets to the PCoA of the MN. The MN must still formulate
an NCoA for transmitting FBU (using the information sent in this message),
but that NCoA will not be used for forwarding packets."

-Rajeev

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Jan 2008 21:44:16 +0200

Rajeev,

> The context is that you agreed the protocol does not have to specify
> the security configuration (I would have to dig out the e-mail). Agree
> that you cannot leave mandatory parts. However, here we are assuming
> that the network between the routers is secure (established by means
> beyond the scope of this document). 

But that's just the issue. General IESG rule: Means have to be
specified. You may leave up to the admin to be turned on, but you must
have a specification of how to secure your protocol, and the
implementation of that has to be mandatory.

Jari

---

From: "Rajeev Koodli" <[email-masked]>
Date: Wed, 16 Jan 2008 12:34:06 -0800

Below are couple of exchanges on this (going back to Oct/Nov)..I revised
version 03 based on this.

-Rajeev

.............................

>> In the security considerations section you say that IPsec is used for
>> this purpose. I would actually not talk about security associations as
>> such. But you need to specify mandatory-to-implement security
>> functionality and the expected configuration:
>>
>> - use of IPsec
>> - use of key management protocol for IPsec
>> - security policy and credential/shared secret configuration
>>
>>
>
> Isn't this deployment-specific? The protocol is not specifying key
> management, SA configuration.
>

I have taken a new look at this part of the document and
BCP 107, and reconsidered. You do not actually have a situation that
would absolutely require a mandatory to implement key
management protocol to be specified.

(You may want to specify an optional one for interoperability
purposes, however. This should not be hard. But I'll let you
decide.)

..................

---

From: Jari Arkko <[email-masked]>
Date: Wed, 16 Jan 2008 22:40:53 +0200

Rajeev,

> Below are couple of exchanges on this (going back to Oct/Nov)..
> I revised version 03 based on this. 

Ah. Thanks for digging this up! Now I can recall what we talked about.

However, my comment that for this specific purpose *key management* is
something that you could leave out. Not the security mechanism itself.
I.e., you have to at least specify what mechanism you use to secure the
messages, and if your answer is IPsec, talk about what kind of
configuration (security policies etc) need to be used.

Sorry for being unclear about this earlier.

(Even key management is still highly recommended for everything, but
your case does not fall under the MUST clause in BCP 107 Section 2.1)

Jari

---

From: "Rajeev Koodli" <[email-masked]>
Date: Wed, 16 Jan 2008 13:48:23 -0800

All right. I will add some text.I do need to add the codepoint for NETLMM
case for PrRtAdv we had talked about. Other than that, I think I have
addressed all the issues we had discussed.

-Rajeev

---

From: <[email-masked]>
Date: Thu, 17 Jan 2008 09:52:34 +0000

Hello,   I have submitted a new draft related to FMIPv6 titled "Pro-active  Bindings for FMIPv6" that deals will reducing the tunnel duration and  hence preserve resources at PAR and NAR and reduce the RTT for applications.   The draft is available under the following link: http://tools.ietf.org/id/draft-yousaf-ietf-mipshop-pbfmipv6-00.txt   I would appreciate expert comments and critique on it.   Looking forward   Best Regards   Faqir Zarrar Yousaf 
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging.  You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Jan 2008 18:55:50 +0200

Rajeev,

>
> On Jan 15, 2008 6:39 AM, Jari Arkko <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
> The additional requirement specified by this document is to send UNA
> as soon as attachment to NAR is detected. Other than that, it does not
> impose any other requirements. Hence, there are no implications as
> stated in Section 7.

Ok. Can you a statement somewhere that FMIP expects all the usual ND
operations to be performed on the new link, and that the UNA is the only
change? Unless, of course, you have that somewhere already...

> No, NCoA is not used before DHCP grants address. Packet forwarding
> happens using PCoA.
> NCoA is used only in FBU following the usual semantics. This is
> explained further in Section 6.1 
>
> " A Proxy Router Advertisement with Code 5 means that the MN may
> use the new router information present for detecting movement to a new
> subnet, but the MN must perform DHCP [rfc3315] upon attaching to the
> NAR's link. The PAR and NAR will forward packets to the PCoA of the
> MN. The MN must still formulate an NCoA for transmitting FBU (using
> the information sent in this message), but that NCoA will not be used
> for forwarding packets."

Ok, but can you add some of the above explanation you gave me to the
text that I quoted?

Jari

---

From: "Rajeev Koodli" <[email-masked]>
Date: Fri, 18 Jan 2008 09:26:59 -0800

Okay.
-Rajeev

---

From: Jari Arkko <[email-masked]>
Date: Fri, 18 Jan 2008 20:17:28 +0200

I have now reviewed the new version. Most of the issues are now in
order. The remaining ones:

- Specification of how to employ ipsec between the routers

- Address uniqueness testing, as discussed previously.

- Words to clarify that code point 5 applies (Section 6.1.2)
  to netlmm as well.

- Clarification what unrecognized LLA means.

- Clarification about comparison lack of flooding protection in mobile
ipv6 (ha case).

- Issue about trusting LLA information from FBU/HI.

- The two clarifications from my other mail that I just sent.

Details below.

Jari

> *Comment:*I have made my AD review on this document. Or at least
> started the work, as I had many questions; when I have answers to
> those questions I can complete my review.
>
> I suspect that the document needs another spin in the WG, but lets
> talk about that when I know more about the answers to my questions. I
> also have not read the companion document yet. It is possible that it
> would have answered some of my questions.
>
> Overall, there are a number of issues. Some of the highest level
> issues include
>
> - Interaction with duplicate address detection, and how duplicates are
> avoided needs further work.
>
> - Clearer specification is needed on what the hosts have to do on the
> new link wrt. existing ND procedures.
>
> - Security considerations need to be expanded and clarified.
>
> - Need to be capable of indicating netlmm-like functionality where the
> same prefix follows the mobile node on a new link.
>
> - What happens when the DHCP, not stateless address autoconfiguration
> is used in the network? Or is that prohibited?
>
> - This document introduces a number of new Neighbor Discovery
> messages. Should this document also specify how SEND (if used) is
> applied on them?
>
> - What changes, if any, are needed to the conceptual data structures
> held by ND?
>
> - A fair number of protocol details need correction and/or clarification.
>
> Given the tight integration to ND functions, I have also asked for
> review from the IETF ND experts in the IP Directorate.
>
> In more detail, here are the substantial issues:
>
> >    When it is not feasible, FBU is sent from the new link.  Care must be
> >    taken to ensure that NCoA used in FBU does not conflict with an
> >    address already in use by some other node on link.
>
> How? Be more specific.

Fixed.

>
> > For all these operations, the protocol provides
> >    "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages
> >    (see Section 6.2).  Both of these messages SHOULD be used.  The
> >    access routers MUST have necessary security association established
> >    by means outside the scope of this document.
>

We talked about this, and this still needs work. Basically, you can if
you insist, leave the key management out. But you still need to describe
the basic mechanism and provide an explanation how it is used. ("Just
use IPsec is not sufficient").

> >      2.  The MN does not receive FBack on the previous link.  One
> >      reason for this is that the MN has not sent the FBU.  The other is
> >      that the MN has left the link after sending the FBU, which may be
> >      lost, but before receiving an FBack.  Without receiving an FBack
> >      in the latter case, the MN cannot ascertain whether PAR has
> >      successfully processed the FBU.  Hence, the MN (re)sends FBU
> >      immediately after sending the UNA message.  If NAR detects that
> >      NCoA is in use when processing UNA, for instance while creating a
> >      neighbor entry, it sends a Router Advertisement with "Neighbor
> >      Advertisement Acknowledge (NAACK)" option in which NAR MAY include
> >      an alternate IP address for the MN to use.
>
> But if the MN leaves before FBack has arrived, how does the MN
> differentiate between the NAR defending his address vs. some other
> node already using it?

OK per your explanation.

> >      1. determines whether NCoA supplied in the HI message is a valid
> >      address for use, and if it is, starts proxying [rfc2461] the
> >      address for PROXY_ND_LIFETIME during which the MN is expected to
> >      connect to NAR.  In case there is already an NCoA present, NAR may
> >      verify if the LLA is the same as its own or that of the MN itself.
> >      If so, NAR may allow the use of NCoA.
>
> 1) How does the NAR know what addresses are present on the link?

This is the address duplication issue.
>
> 2) For the case that LLA equals the MN's LLA: how do we know that the
> LLA in the HI message is not spoofed?
We had a discussion about this earlier and agreed to state that you need to
state there is an assumption that the two routers trust each other. But
when I am looking at the document again, I am still concerned. The issue
is that the LLA information does not come from the other router, it merely
comes through it. If I am another MN on the other link, I can fool the
NAR into thinking that I am the same node by claiming that I have the
same IP address and MAC address as the victim.

> >      2.  If the new access point is connected to the PAR's current
> >      interface (to which MN is attached), PAR responds with a Code
> >      value indicating that the new access point is connected to the
> >      current interface, but not send any prefix information.  This
> >      scenario could arise, for example, when several wireless access
> >      points are bridged into a wired network.  No further protocol
> >      action is necessary.
>
> This is good. But I wonder about two things:
>
> 1) Is there something that you need to specify about interactions
> regarding current ND rules on new links? Are there 2461bis rules that
> change as a result? this RFC updates RFC 2461bis? The same question
> would also apply to DNA, but the new DNA design isn't ready yet.
>
> 2) Is there something that you should do in order to ensure that
> non-L3 entities on the path learn the things they need. For instance,
> MLD snooping switches (RFC 4541)?

Here is a proposed change to Section 7:

OLD:
   The protocol specifies an optional extension to Neighbor
   Discovery [rfc4861] in which an access router may send a router
   advertisement as a response to the UNA message (see Section
   Section 6.4).
NEW:
   The protocol specifies an optional extension to Neighbor
   Discovery [rfc4861] in which an access router may send a router
   advertisement as a response to the UNA message (see Section
   Section 6.4). Other than this, this protocol does not change the
   Neighbor Discovery behaviour in any way, including both procedures
   performed while attached to the link and when attaching to a new
   link.

> >    Once the MN has confirmed its NCoA (either through DAD or when
> >    provided for by the NAR), it SHOULD send a Neighbor Advertisement
> >    message with the 'O' bit set, to the all-nodes multicast address.
> >    This message allows MN's neighbors to update their neighbor cache
> >    entries.
>
> Is reference to 4861 Section 7.2.6 needed? Which of the requirements
> from that section apply, which do not? For instance, are there
> requirements on the maximum number of such messages per unit of time?

There are changes in Section 6.4. It would have been good to have
something explicit in the above text as well. But this is a comment
only, address this if you can but it does not block starting Last Call.

> > However, the MN itself does not have to
> >    wait on PAR's link for this exchange to take place.  It can handover
> >    any time after sending the FBU message; sometimes it may be forced to
> >    handover without sending the FBU.  In any case, it can still confirm
> >    using NCoA from NAR's link by sending the UNA message.
>
> But if it does this too early, won't the NAR detect a collision for
> the new care of address?

Part of the collision issue.

> >    When per-mobile prefix assignment is used, the ``AR-Info'' advertised
> >    in PrRtAdv still includes the (aggregate) prefix valid on the
> >    interface to which the target AP is attached, unless the access
> >    routers communicate with each other (using HI and HAck messages) to
> >    manage per-mobile prefix.  The MN still formulates an NCoA using the
> >    aggregate prefix.  However, an alternate NCoA based on the per-mobile
> >    prefix is returned by NAR in the HAck message.  This alternate NCoA
> >    is provided to the MN in either the FBack message or in the NAACK
> >    option.
> Note that you earlier in Section 4 you described the three possible
> outcomes that the PrRtAdv message can give you (unknown, same
> interface, known other router).
>
> You should also take into account things like NETLMM, where it is
> possible that there's a different device but the network keeps the
> mobile's prefix intact.

Not handled. I would suggest the following change in Section 6.1.2:

OLD:
      When the Option-Code field in the New Access Point LLA option is
      5, handover to that access point does not require change of CoA.
      No other options are required in this case.
NEW:
      When the Option-Code field in the New Access Point LLA option is
      5, handover to that access point does not require change of CoA.
      This is the case, for instance, when a number of access points
      are connected to the same router interface, or when network
      based mobility mechanisms ensure that the specific mobile
      node always sees the same prefix no matter where it attaches to.

      No other options are required in this case.

>
> >    This document specifies messages which can be used to provide
> >    duplicate-free addresses but the document does not specify how to
> >    create or manage such duplicate-free addresses.  In some cases the
> >    NAR may already have the knowledge required to assess whether the
> >    MN's address is a duplicate or not before the MN moves to the new
> >    subnet.  For example, the NAR can have a list of all nodes on its
> >    point-to-point radio network, and by searching this list, it can
> >    confirm whether the MN's address is a duplicate or not.
>
> I do not understand how this is possible. On a shared link you would
> not know if there are other nodes that have decided to adopt a given
> address. On a point-to-point link you would presumably give different
> prefixes for the different links, so its not clear why the addresses
> of the other nodes even matter.
>
> More specification and/or more accurate description of limitations needed.

Part of the collision issue.

> >          New Router's IP Address: The IP address of NAR.  This option
> >          MUST be included when Code is 0 or 1.
> >
> >          New Router Prefix Information Option: Specifies the prefix of
> >          the Access Router the message is proxied for and is used for
> >          address auto-configuration.  This option MUST be included when
> >          Code is 0 or 1.  However, when this prefix is the same as what
> >          is used in the New Router's IP Address option (above), the
> >          Prefix Information option need not be present.
> If so, what would the prefix length be?

This was OK based on your earlier explanation.

>
> >      2.  The MN does not receive FBack on the previous link.  One
> >      reason for this is that the MN has not sent the FBU.  The other is
> >      that the MN has left the link after sending the FBU, which may be
> >      lost, but before receiving an FBack.  Without receiving an FBack
> >      in the latter case, the MN cannot ascertain whether PAR has
> >      successfully processed the FBU.  Hence, the MN (re)sends FBU
> >      immediately after sending the UNA message.  If NAR detects that
> ...
>
> >    The MN sends FBU message any time after receiving a PrRtAdv message.
> >    If the MN moves prior to receiving a PrRtAdv message, it SHOULD send
> >    a FBU to the PAR after configuring NCoA on the NAR according to
> >    Neighbor Discovery and IPv6 Address Configuration protocols.
>
> There appears to be a contradiction. In the first paragraph you say
> that the UNA is sent on the new link, whereas in the latter case you
> say that plain old ND protocols are run (presumably DAD would be
> included). Which is it?
Document changed, ok.

>
> >    The source IP address is PCoA when FBU is sent from PAR's link, and
> >    the source IP address is NCoA when sent from NAR's link.
> >
> >    The FBU MUST also include the Home Address Option and the Home
> >    Address is PCoA.  A FBU message MUST be protected so that PAR is able
> >    to determine that the FBU message is sent by a genuine MN.
> Is the HAO included even when the source address is the PCoA?

I'm withdrawing my comment after re-reading RFC 3775 :-)

>
> >      `K' flag: See See [rfc3775].
>
>
> I am surprised to see K flag here. Its use does not appear to be
> possible, given that movements between NAR and PAR do not merely
> change the address of one of the participants, but the node itself
> changes. Sharing of key state is not recommended.

Fixed.

> > 6.4. Unsolicited Neighbor Advertisement (UNA)
> >
> >    This is the same message as in [rfc2461] with the requirement that
> >    the 'O' bit is always set to zero.  Since this is an unsolicited
> >    message, the 'S' bit is zero, and since this is sent by a MN, the 'R'
> >    bit is also zero.
> >
> >    The Source Address must be the NCoA.  The Destination Address is
> >    typically the all-nodes multicast address; however, some deployments
> >    may not prefer transmission to a multicast address.  In such cases,
> >    the Destination Address SHOULD be the NAR's IP address.
> >
> >    The Target Address must include the NCoA, and Target link-layer
> >    address must include the MN's LLA.
> >
> >    The MN sends a UNA message to the NAR, as soon as it regains
> >    connectivity on the new link.  Arriving or buffered packets can be
> >    immediately forwarded.  If NAR is proxying NCoA, it creates a
> >    neighbor cache entry in STALE state but forwards packets as it
> >    determines bidirectional reachability.  If there is an entry in
> >    INCOMPLETE state without a link-layer address, it sets it to STALE.
> >    If there is no entry at all, creating an entry in STALE state is
> >    recommended since forwarding can immediately begin when packets
> >    arrive without first invoking Neighbor Solicitation and Advertisement
> >    (which may involve retransmission delay in the event of messages
> >    being lost).  During the process of creating a neighbor cache entry,
> >    NAR can also detect if NCoA is in use, and immediately sends a Router
> >    Advertisement with NAACK option in the event of collision.
> >
> >    The combination of NCoA (present in source IP address) and the Link-
> >    Layer Address (present as a Target LLA) SHOULD be used to distinguish
> >    the MN from other nodes.
>
> I would like to understand whether the behaviour for the router
> differs from that specified in RFC 2461. If not, please refer to the
> right RFC and make sure that the above is merely an explanation of
> what happens. If yes, the use of the same message as in ND may be
> inappropriate.

OK now. Thanks.

> > During the process of creating a neighbor cache entry,
> >    NAR can also detect if NCoA is in use, and immediately sends a Router
> >    Advertisement with NAACK option in the event of collision.
> How does it detect this?
>
> Also, what if a legacy IPv6 node sends a regular UNA message. How do
> you know this is a request to confirm the NCoA vs. merely the desire
> of a host to re-assert that it is at this link layer address?

All part of the collision question.

> > If the NAACK indicates that the Link
> >    Layer Address is unrecognized, the MN MUST NOT use the NCoA or the
> >    PCoA and SHOULD start immediately the process of acquiring different
> >    NCoA at the NAR.
> How does the router decide that a link layer address is
> "unrecognized"? Presumably it is never unrecognized, given that this
> address must have appeared in the UNA.

No changes done here. You explained:

If the LLA in UNA was from another radio link than the one to which the MN
(and the NAR) is currently attached to.

Please add some words about this to the document.

> >    The following security vulnerabilities are identified, and suggested
> >    solutions mentioned.
>
> This section should clearly list the solutions that are mandatory to
> implement.

Still work here.

> >      If an access router can ensure that the source IP address in an
> >      arriving packet could only have originated from the node whose
> >      link-layer address is in the router's neighbor cache, then a bogus
> >      node cannot use a victim's IP address for malicious redirection of
> >      traffic.  Such an operation is recommended at least on neighbor
> >      discovery messages including the RtSolPr message.
> How the router ensure that the packet can only have come from the
> right node? Note that you can also spoof L2 addresses. Please explain.

Ok, text removed.

> >      Secure FBU, malicious or inadvertent redirection: in this case,
> >      the FBU is secured, but the target of binding happens to be an
> >      unsuspecting node either due to inadvertent operation or due to
> >      malicious intent.  This vulnerability can lead to a MN with
> >      genuine security association with its access router redirecting
> >      traffic to an incorrect address.
> >      However, the target of malicious traffic redirection is limited to
> >      an interface on an access router with which the PAR has a security
> >      association.  The PAR MUST verify that the NCoA to which PCoA is
> >      being bound actually belongs to NAR's prefix.  In order to do
> >      this, HI and HAck message exchanges are to be used.  When NAR
> >      accepts NCoA in HI (with Code = 0), it proxies NCoA so that any
> >      arriving packets are not sent on the link until the MN attaches
> >      and announces itself through UNA.  So, any inadvertent or
> >      malicious redirection to a host is avoided.  It is still possible
> >      to jam NAR's buffer with redirected traffic.  However, since NAR's
> >      handover state corresponding to NCoA has a finite (and short)
> >      lifetime corresponding to a small multiple of anticipated handover
> >      latency, the extent of this vulnerability is arguably small.
> I have a hard time understanding what is being said here. Do you mean
> the vulnerability where a host redirects its own traffic to a victim?
> Or a host redirecting victim's traffic to itself or some third party?

Ok with earlier explanations.

> >      Sending FBU from NAR's link: a malicious node may send FBU from
> >      NAR's link providing an unsuspecting node's address as NCoA.  This
> >      is similar to base Mobile IP where the MN can provide some other
> >      node's IP address as its CoA to its Home Agent.  As in base Mobile
> >      IP, the extent of such a misdelivery can be controlled and
> >      recovery is possible.  In addition, it is possible to isolate the
> >      MN if it continues to misbehave.
>
> But Mobile IPv6 has mechanisms (care of address test) to deal with
> this. What mechanisms does FMIP have for this?

Your explanation comparing NAR/PAR to a HA was good, but I think it
needs to be in the document.

> >    compromised, the MN's RtSolPr message may be answered by an attacker
> >    that provides a rogue router as the resolution.  Should the MN attach
> >    to such a rogue router, its communication can be compromised.
> >    Similarly, a network-initiated PrRtAdv message (see Section 3.3) from
> >    an attacker could cause a MN to handover to a rogue router.  Where
> >    these weaknesses are a concern, a solution such as Secure Neighbor
> >    Discovery (SEND) [rfc3971] SHOULD be considered.
> But this specification does not provide details to do so. I would
> suggest describing the rules to be used for securing the new ND
> messages with SEND, here. Assuming it is not in the companion document
> yet...

I looked at the two documents now and I'm satisfied with what they have.

> >  The HI and HAck messages between the access routers need to be
> >    secured using a pre-existing security association between the access
> >    routers to ensure at least message integrity and authentication, and
> >    should also include encryption.  For this, IPsec ESP [rfc2406]
> >    authentication MUST be used and IPsec ESP encryption SHOULD be used.
> Some words about the expected configuration would be needed here.
> E.g., policies set to protecting all ICMPv6 type XXX messages between
> specific pairs of routers.

This is needed, as discussed previously.

> Editorial:

Not checked.

Jari

>
> >    Mobile IPv6 [rfc3775] describes the protocol operations for a mobile
> >    node to maintain connectivity to the Internet during its handover
> >    from one access router to another.  These operations involve movement
> >    detection, IP address configuration, and location update.
>
> This presents an IP layer centric view of the situation. In reality,
> link layer signaling is also a significant factor in how efficiently
> handover can be performed. Suggested rewrite:
>
>   Mobile IPv6 [rfc3775] describes the protocol operations for a mobile
>   node to maintain connectivity to the Internet during its handover
>   from one access router to another.  These operations involve link layer
>   procedures, movement detection at IP layer, IP address configuration,
>   and location update.
>
> >    The ability to immediately send packets from a new subnet link
> >    depends on the "IP connectivity" latency, which in turn depends on
> >    the movement detection latency and the new CoA configuration latency.
> As above.
>
> >      3. starts a DAD probe for NCoA.  See [rfc2462].
> References need updating to the new RFCs. Applies to the ND RFCs as
> well as IPsec RFCs.
>
> >    can be up to RTSOLPR|RETRIES, but MUST use an exponential backoff in
>
> I see a bar, not underscore in the name. Is this what was intended?
>
>
> >      When the Option-Code field in the New Access Point LLA option is
> >      7, it means that the NAR does not support fast handover.  The MN
> >      MUST stop fast handover protocol operations.  No other options are
> >      required in this case.
> >
> >      A Proxy Router Advertisement with Code 3 means that new router
> >      information is present only for a subset of access points
> >      requested.  The Option-Code field values (defined above including
> >      a value of 1) distinguish different outcomes for individual access
> >      points.
> The second paragraph and onwards should not have the same indentation.
>
> >    to determine that the FBU message is sent by a genuine MN.
> "genuine" may not be the right term. s/a genuine MN/the MN that
> legitimately holds the given IP address/.
>
> > Appendix C. Change Log
> Differences to RFC 4068 list would be useful.

---

From: "Rajeev Koodli" <[email-masked]>
Date: Fri, 25 Jan 2008 11:47:17 -0800

Hi Jari,
thanks. I will respond to the ones which need further clarification.

Okay.

> - Address uniqueness testing, as discussed previously.

I have revised text about this. Major sections are 5.5 and 6.4. I see a
place below you mention which I can revise.

Okay.

Okay.

> - Clarification about comparison lack of flooding protection in mobile

Check.

> - Issue about trusting LLA information from FBU/HI.

See below.

Yes.

> use IPsec is not sufficient").

Yes, okay.

> This is the address duplication issue.

As we have agreed, typically NAR may not have means to keep a list of all
the addresses on the link, although it is feasible with a data structure
like "visitor list" in MIP4 or an access control list when access control is
enforced. For our purposes here, I can reword the above to "In case there is
already an NCoA present in its neighbor cache, .."

> same IP address and MAC address as the victim.

So, the issue is whether the MN which can provide an authenticated FBU could
abuse the use of LLA? (That's what I can gather by "spoofing the LLA" in HI
message).

Okay.

> Part of the collision issue.

 The protocol a) allows a deployment to maintain duplicate-free addresses
(by means beyond the scope of the protocol) and provides HI and HAck for
exchange, b) states that it SHOULD only be used where the probability of
collision is extremely low. This is specified in Section 5.5 and same holds
above. Please let me know if you would like me to reword anything.

Ok, good.

> Part of the collision issue.

I have revised Section 5.3 as per the above discussion (perhaps you are
missing my responses to your points above).

> I'm withdrawing my comment after re-reading RFC 3775 :-)

So, we could revert back to always having the HAO right?

> All part of the collision question.

We had discussion on the above. And, I have revised Section 6.4accordingly.

> Please add some words about this to the document.

okay.

> > This section should clearly list the solutions that are mandatory to

okay.

Okay.

Okay.

Okay.

-Rajeev

---

From: Jari Arkko <[email-masked]>
Date: Mon, 28 Jan 2008 14:57:26 +0200

Rajeev,

> As we have agreed, typically NAR may not have means to keep a list of
> all the addresses on the link, although it is feasible with a data
> structure like "visitor list" in MIP4 or an access control list when
> access control is enforced. For our purposes here, I can reword the
> above to "In case there is already an NCoA present in its neighbor
> cache, .."

Ok. Please make sure that you also handle the case where the proxy ND
operation fails due to a collision NOT in the cache.

> So, the issue is whether the MN which can provide an authenticated FBU
> could abuse the use of LLA? (That's what I can gather by "spoofing the
> LLA" in HI message).

Right. What is the LLA information used for?

>  The protocol a) allows a deployment to maintain duplicate-free
> addresses (by means beyond the scope of the protocol) and provides HI
> and HAck for exchange, b) states that it SHOULD only be used where the
> probability of collision is extremely low. This is specified in
> Section 5.5 and same holds above. Please let me know if you would like
> me to reword anything.

I thought that due to changes mentioned earlier in this e-mail, you now
are doing
proxy ND on behalf of mobile nodes, so you DO appear to specify a
mechanism for
providing duplicate-free addresses.

I think that is required. If in addition you want to specify that in
environments
where the probability of collision is very low people can turn of DAD (by
setting DupAddrDetectTransmits to 0 per RFC 4862), that's fine. But it is
not fine to say that this protocol only works if there are no collisions.

Yes.
 
Jari

---

From: "Rajeev Koodli" <[email-masked]>
Date: Mon, 28 Jan 2008 10:03:54 -0800

> operation fails due to a collision NOT in the cache.

Ok. I will reword.

> Right. What is the LLA information used for?

The combination of LLA and NCoA is used to identify the MN.

Since we trust the MN to the extent that the FBU is authenticated, we also
expect the LLA to be genuine.
This is similar to the MN, which otherwise has an SA with the HA,
misbehaving which we have talked earlier. I can include this also in the
Security Considerations if you want.

> providing duplicate-free addresses.

Proxy ND operation specification has been there for a long time..Note that
the NAR defends the address once it is known to be duplicate-free. We do not
specify how the NAR arrives at that resolution: it could be that it
maintains a pool or by any other means.

> not fine to say that this protocol only works if there are no collisions.

No. It is designed for the most prevalent scenarios where there are no
collisions (either due to the availability of duplicate-free addresses or
due to the extremely low probability of address collisions). The recovery
operations, in the extremely unlikely event of collisions, are described in
the appendix.

Okay.

Thanks,

-Rajeev

---

From: Jari Arkko <[email-masked]>
Date: Tue, 29 Jan 2008 13:13:24 +0200

Rajeev,

> Since we trust the MN to the extent that the FBU is authenticated, we
> also expect the LLA to be genuine.
> misbehaving which we have talked earlier. I can include this also in
> the Security Considerations if you want.

You do not authenticate MNs because you trust them; you authenticate
them because otherwise some other nodes might claim they are the MN.
Similarly with this, even when you authenticate the node in question,
you want to ensure that the authenticated identity actually has been
authorized to do whatever action it claims it wants to do.

In the simplest case this would mean things like establishing a security
association with a particular node and then storing its IP and MAC
addresses, and then later when that particular security association is
used, refuse to accept any other IP or MAC address.

I think you should state something similar here.

> Proxy ND operation specification has been there for a long time..Note
> that the NAR defends the address once it is known to be
> duplicate-free. We do not specify how the NAR arrives at that
> resolution: it could be that it maintains a pool or by any other means.

This seems backwards. If you actually do have proxy ND, you should use
it to find out whether the address is duplicate-free. The mechanisms and
protocols for this exist; you only pay in terms of some DAD delay.
However, since that is already configurable per link, I really don't see
much of a problem.
 
> collisions (either due to the availability of duplicate-free addresses
> or due to the extremely low probability of address collisions). The
> recovery operations, in the extremely unlikely event of collisions,
> are described in the appendix.

Rajeev, it is a PS-level requirement that you be able to operate in IPv6
the way IPv6 is normally is run. We can debate about which scenario is
more prevalent, but it would be pointless. All you need to do is to
provide support for both. We can't publish PS specs that do not have
complete functionality for what they do, or that force us to disable
something that is core functionality in ND.

Jari

---

From: "Rajeev Koodli" <[email-masked]>
Date: Tue, 29 Jan 2008 10:17:47 -0800

Hi Jari,

> authorized to do whatever action it claims it wants to do.

Yes, yet the HA trusts the MN to be at CoA (i.e., no RR) in MIP6. I guess
this is not the right place to discuss this, and I did not imply that you
trust someone carte blanche because you authenticated them (".. to the
_extent_ that FBU is authenticated.."). Clearly, authentication and
authorization are separate but related concepts, and trust is a function of
the domain in which you perform both.

Ok.

> However, since that is already configurable per link, I really don't see

The issue is when you perform these operations.. When NAR receives HI, if it
engages in these operations, that adds to the critical handover delay. So,
the design separates the two: NAR can maintain a pool (and do proxy ND if
necessary) which is duplicate-free, and provide messages to transport the
NCoA.

> something that is core functionality in ND.
I was only providing the design rationale..

In sum, a) proxy ND is used to defend an address like in an HA (it could
also be used to maintain a pool of duplicate-free addresses for which the
protocol provides a transport message for), and b) DAD could be turned off
depending on specific deployment consideration (i.e., address collision is
not an issue)

Is this okay?

Thanks,

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 30 Jan 2008 15:44:14 -0800

Hi Rajeev,

Rajeev Koodli wrote:
> also be used to maintain a pool of duplicate-free addresses for which 
> the protocol provides a transport message for), and b) DAD could be 
> turned off depending on specific deployment consideration (i.e., address 
> collision is not an issue)

I think this should be explained in more detail. How about the
following?

The NAR checks if the address is unique before starting
defending it. The NAR sends a DAD (neighbor solicitation) message
for the NCoA to check if the address is unique on the NAR link.
If there are other mechanisms by which the NAR can figure out if
the address is unique or if it is known that the probability of
collisions is very low or non-existent, then the parameter
DupAddrDetectTransmits is set to 0 on the NAR.

Vijay

---

From: "Rajeev Koodli" <[email-masked]>
Date: Thu, 31 Jan 2008 10:50:54 -0800

> DupAddrDetectTransmits is set to 0 on the NAR.

Sounds good.

-Rajeev