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

[Rajeev Koodli <rajeev.koodli at nokia.com>]

Hi Jari,

Thanks for your review.

On 10/23/07 3:22 PM, "ext Jari Arkko" <jari.arkko at piuha.net> wrote:

> 
> - Interaction with duplicate address detection, and how duplicates are
> 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.



> - Clearer specification is needed on what the hosts have to do on the
> 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..

> 
> - Need to be capable of indicating netlmm-like functionality where the
> 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

> - What happens when DHCP, not stateless address autoconfiguration is
> 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


> - This document introduces a number of new Neighbor Discovery messages.
> 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
> held by ND?

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

> 
> Given the tight integration to ND functions, I have also asked for
> 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. 


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

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


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

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


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

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



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

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

> 
> 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 assume that HI and Hack are between trustworthy routers which have SA
between them. 

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

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

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

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.


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

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?



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

I didn't quite follow this..


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

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.

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

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.



>>    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 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
> prefixes for the different links, so its not clear why the addresses of
> the other nodes even matter.
> 

Right. This needs to be clarified.

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

The Prefix Length field in Section 6.5.1 indicates this.

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

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.



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

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


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

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.

 
>>       6.4. Unsolicited Neighbor Advertisement (UNA)
>> 
>>    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.

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. 


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

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

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

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


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

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


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

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



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

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


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

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



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

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


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

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.



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

See my comment (way) above.


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

Okay.


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

Okay.


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

Ah, typo.


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

Okay.

Thanks,

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



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