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

[Jari Arkko <jari.arkko at piuha.net>]

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
Mipshop at ietf.org
https://www1.ietf.org/mailman/listinfo/mipshop