On Jan 18, 2008 10:17 AM, Jari Arkko <
jari.arkko at piuha.net> wrote:
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
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.
- Words to clarify that code point 5 applies (Section 6.1.2)
to netlmm as well.
Okay.
- Clarification what unrecognized LLA means.
Okay.
- Clarification about comparison lack of flooding protection in mobile
ipv6 (ha case).
Check.
- Issue about trusting LLA information from FBU/HI.
See below.
- The two clarifications from my other mail that I just sent.
Yes.
> - use of IPsec
> - use of key management protocol for IPsec
> - security policy and credential/shared secret configuration
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").
Yes, okay.
> > 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.
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, .."
>
> 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.
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).
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.
Okay.
> > 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.
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.
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.
Ok, good.
>
> > 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.
I have revised Section 5.3 as per the above discussion (perhaps you are missing my responses to your points above).
>
> > 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 :-)
So, we could revert back to always having the HAO right?
> > 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.
We had discussion on the above. And, I have revised Section 6.4 accordingly.
> 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.
okay.
> > 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.
okay.
>
> 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.
Okay.
> 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.
Okay.
> > 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.
Okay.
-Rajeev
>
> 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.
