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

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Oct 2007 00:22:06 +0200

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 later. 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 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.

> For all these operations, the protocol provides
>    "Handover Initiate (HI)" and "Handover Acknowledge (HAck)" messages
>    (see Section 6.2 <http://tools.ietf.org/html/draft-ietf-mipshop-fmipv6-rfc4068bis-03#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.

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

>       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?

>       1. determines whether NCoA supplied in the HI message is a valid
>       address for use, and if it is, starts proxying [rfc2461 <http://tools.ietf.org/html/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?

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?

>       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)?

>    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?

> 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?
>    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.

>    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.

>          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?

>       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?

>    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?

>       `K' flag: See See [rfc3775 <http://tools.ietf.org/html/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.

>
>       6.4. Unsolicited Neighbor Advertisement (UNA)
>
>
>    This is the same message as in [rfc2461 <http://tools.ietf.org/html/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.

> 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?
> 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.

>    The following security vulnerabilities are identified, and suggested
>    solutions mentioned.
>   

This section should clearly list the solutions that are mandatory to
implement.

>       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.

>       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?

>       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?

>    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 <http://tools.ietf.org/html/draft-ietf-mipshop-fmipv6-rfc4068bis-03#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 <http://tools.ietf.org/html/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...

>   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 <http://tools.ietf.org/html/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.

Editorial:

>    Mobile IPv6 [rfc3775 <http://tools.ietf.org/html/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 <http://tools.ietf.org/html/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 <http://tools.ietf.org/html/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.

Jari

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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 24 Oct 2007 15:23:08 -0700

Hi Jari,

Thanks for your review.

> avoided needs further work.

Section 4, Page 14:

" As soon as the MN establishes link connectivity with the NAR, it

      1. sends a UNA message (see Section 6.4).  If the MN has not
      received an FBack by the time UNA is being sent, it SHOULD send an
      FBU message following the UNA message.

      2. joins the all-nodes multicast group and the solicited-node
      multicast group corresponding to the NCoA

      3. starts a DAD probe for NCoA.  See [rfc2462]."

Section 4, Page 15:

   "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."

Section 5.5 is for DAD handling.

The protocol does not specify how to avoid duplicates. When duplicate-free
addresses are available at NAR, it specifies the container messages (HAck,
FBack, NAACK option) to provide them.

> new link wrt. existing ND procedures.

A host does what it normally does when it attaches to a new link wrt to ND
operations. In addition, it sends messages defined by the protocol. See
above (section 4, page 14).

In general, the protocol does not require changes to other protocols, their
timing etc, including MIP6.

> - Security considerations need to be expanded and clarified.

Could you please be more specific? I will look below..

> same prefix follows the mobile node on a new link.

Hmm.. Does that belong here? There is an ID on the topic:

http://www.ietf.org/internet-drafts/draft-yokota-mipshop-pfmipv6-00.txt

> used in the network? Or is that prohibited?

Two cases:

- NAR provides an address from a pool (in which case, any DHCP messages from
the MN on the new link are also answered by the NAR)
- protocol simply supports forwarding for PCoA, which allows the MN to go
about doing DHCP operations as usual

> Should this document also specify how SEND (if used) is applied on them?

Actually, the document does not introduce any new ND messages. They are
ICMPv6 messages. The security consideration section refers to using SEND on
RtSolPr and PrRtAdv messages.

> - What changes, if any, are needed to the conceptual data structures

No changes to the data structures held by ND. No new state being defined.

> - A fair number of protocol details need correction and/or clarification.

I guess you will point them out.. :-)

> review from the IETF ND experts in the IP Directorate.

I would like to understand this better. Other than specifying that an RA MAY
be sent as a response to the Unsolicited NA, I am wondering where there is
tight integration. I also agree it specifies using proxy NA functionality
when the NAR defends an address.

As a reference, folks at fmipv6.org have implemented it at as a userland
program in Linux. 

>>    address already in use by some other node on link.

The last sentence does not belong anymore (some old, remaining text..)

>>    (see Section 6.2
>> <http://tools.ietf.org/html/draft-ietf-mipshop-fmipv6-rfc4068bis-03#section-6
>> .2>).  Both of these messages SHOULD be used.  The

Isn't this deployment-specific? The protocol is not specifying key
management, SA configuration.

> differentiate between the NAR defending his address vs. some other node

It does not. Hence it sends the UNA message first which has its LLA and the
NCoA. 

>>       address for use, and if it is, starts proxying [rfc2461
>> <http://tools.ietf.org/html/rfc2461>] the

The above assumes that the NAR can only know those addresses which are
present in its NCE. When creating an NCE, NAR can check if the new "node"
being created is already in the linked list (or a similar data structure).

> LLA in the HI message is not spoofed?

We assume that HI and Hack are between trustworthy routers which have SA
between them. 

> would also apply to DNA, but the new DNA design isn't ready yet.

AFAICT, no. The PAR is only informing the MN that it is going to an AN which
is on the same subnet as the MN is currently on (hence, no further protocol
action is necessary).

> snooping switches (RFC 4541)?

I don't think that non-L3 nodes need to behave differently. What we need is
the knowledge that a target L2 device (i.e., AP) is on a different subnet
(or not) for IP fast handover purposes.

> requirements on the maximum number of such messages per unit of time?

I guess it depends on the host implementation. For those MNs that do
implement 4861, they should be following the "updates" from 2461 anyway, no?

> But if it does this too early, won't the NAR detect a collision for the

I didn't quite follow this..

> outcomes that the PrRtAdv message can give you (unknown, same interface,

Yes. It's still the case: the prefix in the "known other router" is
aggregate unless the routers exchange per-MN prefix in HI/HAck, and PAR
provides that per-MN prefix in PrRtAdv.

> possible that there's a different device but the network keeps the

Basically, the protocol binds PCoA to NCoA.

In NETLMM, "PCoA" is HoA, and "NCoA" is NAR's IP address. This is how it
works in fmipv4, and it would work the same way here.

I could specify it here. There is also the ID I mentioned above.

> address. 

On such links, the NAR would have to have a pool of duplicate-free addresses
that it can provide. Presumably, you would do stateful configuration on such
links.

> On a point-to-point link you would presumably give different

Right. This needs to be clarified.

> If so, what would the prefix length be?

The Prefix Length field in Section 6.5.1 indicates this.

> plain old ND protocols are run (presumably DAD would be included). Which

Good point. Without PrRtAdv, the MN does not know if it has crossed the
PAR's subnet to NAR's. Hence, it should not send UNA.

I will clarify.

> Is the HAO included even when the source address is the PCoA?

Yes, just to maintain the simplicity of operation. We _could_ state that it
MAY be omitted.

> Sharing of key state is not recommended.

It's there because it is dependent on the security protocol used to
establish the SA, which is specified separately.

You mean the routers by "node" above? If yes, the MN changing the routers is
similar to the MN in MIP changing the routers. The SA is still wrt to PAR
only. It is not shared with NAR; the MN has to establish that separately.

> and make sure that the above is merely an explanation of what happens.

It is pretty much an explanation of what happens. However..

> If yes, the use of the same message as in ND may be inappropriate.

The recommendation above to create an entry in STALE state when there is no
entry at all is new. Also new is sending the RA with NAACK option when
necessary. 

>>    Advertisement with NAACK option in the event of collision.

As it tries to insert a new entry into a linked list, it can see that an
entry already exists.

> host to re-assert that it is at this link layer address?

Such a legacy UNA message will have the 'O' bit set, not cleared.

> Presumably it is never unrecognized, given that this address must have

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

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

So, the required document is the companion SEND-based handovers keys draft.

> node? Note that you can also spoof L2 addresses. Please explain.

Actually, in light of the SEND handovers keys ID, this text can be deleted.

> a host redirecting victim's traffic to itself or some third party?

It's the host redirecting its own traffic to a victim (Secure FBU, malicious
or inadvertent rediretion).

> What mechanisms does FMIP have for this?

CoA Test is not done with the HA.
You could consider the PAR as MN's temporary HA.

>>    Similarly, a network-initiated PrRtAdv message (see Section 3.3
>> <http://tools.ietf.org/html/draft-ietf-mipshop-fmipv6-rfc4068bis-03#section-3
>> .3>) from

It does not because it inherits the weaknesses of ND. I think any
specification on how to secure them using SEND belongs to the companion
document.

> policies set to protecting all ICMPv6 type XXX messages between specific

See my comment (way) above.

>    procedures, movement detection at IP layer, IP address configuration,

Okay.

> References need updating to the new RFCs. Applies to the ND RFCs as well

Okay.

> I see a bar, not underscore in the name. Is this what was intended?

Ah, typo.

> legitimately holds the given IP address/.

Okay.

Thanks,

-Rajeev
-- 
http://people.nokia.net/~rajeev

---

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 26 Oct 2007 16:21:33 +1000

Has this draft already passed WG LC ?  Did I miss the announcement? 

Hesham

 > -----Original Message-----
 > From: Rajeev Koodli [mailto:[email-masked]] 
 > Sent: Thursday, October 25, 2007 8:23 AM
 > To: ext Jari Arkko; 
 > [email-masked]; Mipshop
 > Subject: [Mipshop] Re: AD review of 
 > draft-ietf-mipshop-fmipv6-rfc4068bis
 > 
 > 
 > Hi Jari,
 > 
 > Thanks for your review.
 > 
 > >>    Discovery (SEND) [rfc3971 
 > <http://tools.ietf.org/html/rfc3971>] SHOULD be
 > >> considered.
 > >>    Mobile IPv6 [rfc3775 
 > <http://tools.ietf.org/html/rfc3775>] describes the
 > >> protocol operations for a mobile
 > >    Mobile IPv6 [rfc3775 
 > <http://tools.ietf.org/html/rfc3775>] describes the
 > > protocol operations for a mobile

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 26 Oct 2007 07:35:39 -0700

> Has this draft already passed WG LC ?  Did I miss the announcement? 

The last call started July 8th and expired July 23rd.

Vijay

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 27 Oct 2007 23:37:19 +1000

> The last call started July 8th and expired July 23rd.

=> Yes I know that part but I didn't see an announcement that the draft is
moving on, I saw a request to delay LC because of overlap with the chicago
meeting. 

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Oct 2007 00:00:24 +0200

Rajeev,

Thanks for your quick reply. Sorry that my reply to that has taken a while.

> FBack, NAACK option) to provide them.

That part is ok. However, what still needs clarification is how
the NAR can allocate addresses as currently specified. More
on that later in this e-mail.

> timing etc, including MIP6.

This is good, but I think it should be explicitly stated.

> http://www.ietf.org/internet-drafts/draft-yokota-mipshop-pfmipv6-00.txt

No, that work is about making FMIP proxyable.

What I wanted is to be able to indicate in New Access Point LLA that
the current and new AP will be NETLMMing the interface towards the
host, so no change of CoA needed. You already have code point 5 to
signify no change of care of address. I would like to add words to the
semantics such that NETLMM is covered there.

> about doing DHCP operations as usual

We need text about this in the draft.

> RtSolPr and PrRtAdv messages.

It says "... a solution such as Secure Neighbor
Discovery (SEND) [rfc3971] SHOULD be considered".

But this issue is actually resolved partly in the companion
draft. I would suggest changing the above text to:

"... the use of SEcure Neighbor Discovery (SEND) [RFC 3971]
on the PrRtSol and PrRtAdv messages as defined in [handover]
is suggested."

> No changes to the data structures held by ND. No new state being defined.

I'm surprised if this is the case. Let me ask this in another way.
What data structures does the old and new router have to
maintain to implement this specification?

> As a reference, folks at fmipv6.org have implemented it at as a userland

We can debate about the exact level of tightness. But at the
end of the day, FMIP signaling, RS/RA, DAD, DNA, MLD, etc
have to be done in the same movement operation. I don't see
a big problem, but I want to verify that there aren't unintended
interactions or problems.

> The last sentence does not belong anymore (some old, remaining text..)

Ok.

> 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.)

> It does not. Hence it sends the UNA message first which has its LLA and the

Ok. I would suggest adding some words to the document
about this.

> being created is already in the linked list (or a similar data structure).

Is NCE above Neighbor Cache Entry? Note that its a cache and therefore
not designed to hold everything. And nodes on the link may be communicating
with each other, not needing to go through the router, so the router may not
have their addresses.

> We assume that HI and Hack are between trustworthy routers which have SA

Ok. You should say so.

> is on the same subnet as the MN is currently on (hence, no further protocol

Ok.

> (or not) for IP fast handover purposes.

But an MLD snooping switch would presumably want to know
that a host has changed port, no? I suspect that some of
this needs to be spelled out in the document.

> implement 4861, they should be following the "updates" from 2461 anyway, no?

The question is, does *your* document somehow change the required or
desired behaviour of nodes for sending unsolicited NAs?

Its fine to answer "no", but again I think this is something that should
explicitly be called out. (..., as specified in RFC XXXX Section YY).

> I didn't quite follow this..

Events happen in this order:

1. host initiates fmip on previous link
2. sudden movement to the new link
3. UNA sent to new router, and your document wants that
to create a STALE entry, even if one did not exist before
4. delayed communication between old and new router, old router asking
if the given address is free
5. new router looks up the address from the NCE and sees that it is not
free,
because an entry exists

This would appear to be a problem, but I could be missing something.

> provides that per-MN prefix in PrRtAdv.

Ok.

> that it can provide. Presumably, you would do stateful configuration on such

If so, that needs to be specified and clearly marked
as a requirement.

> Right. This needs to be clarified.

Ok.

> The Prefix Length field in Section 6.5.1 indicates this.

Ah, so it does. Ok.

> PAR's subnet to NAR's. Hence, it should not send UNA.

Ok.

> Yes, just to maintain the simplicity of operation. We _could_ state that it

I would recommend not allowing freedom, simply requiring the option
if the address is not the same, otherwise source address applies.

> only. It is not shared with NAR; the MN has to establish that separately.

Ok.

> entry at all is new. Also new is sending the RA with NAACK option when

Additional behaviour (NAACK) may be fine.

I have somewhat uneasy feeling about the STALE entries, but
I'm not sure I can immediately spot a problem. This could be
one of the reasons why review by traditional ND folks is
useful...

> As it tries to insert a new entry into a linked list, it can see that an

But as discussed earlier, there is no requirement that all nodes
(particular ones that don't do fmip) are in the cache.

> Such a legacy UNA message will have the 'O' bit set, not cleared.

RFC 4861 allows UNAs with both O=0 and O=1. So I think my
question still stands.

> (and the NAR) is currently attached to.

Ok, but this needs to be spelled out.

> So, the required document is the companion SEND-based handovers keys draft.

Ok.

> Actually, in light of the SEND handovers keys ID, this text can be deleted.

Good.

> or inadvertent rediretion).

Ok. Please reword.

> You could consider the PAR as MN's temporary HA.

Ok, but I think you need another type of argument in the text.
The argument is not really about similarity to Mobile IPv6.
In Mobile IPv6, the HA and MN have a relationship, whereas
in FMIP the MN and the router do *not*.

However, there may be another argument about the attack
being local (to the neighbor router only).

> specification on how to secure them using SEND belongs to the companion

Actually, the necessary details are in the companion document. Please
reword this text to make it clearer that this is the case.

> See my comment (way) above.

I'm sorry, I do not remember anything about this particular issue.
I would recommend including guidance about the expected
configuration.

Jari