Subject: [Mipshop] Re: Review of draft-ietf-mipshop-fmipv6-rfc4068bis-02.txt

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Jul 2007 13:45:09 -0700

Hi Jim,

Vijay forwarded your review..Many thanks for the detailed review. Please see
my replies below.

>> --------------------------------
>> 
>> Techincal comments:
>> 
>> 1) Regarding the UNA and NAACK, the initial justification for FMIP
>> having its own fast address uniqueness confirmation protocol rather than use
>> ODAD was that ODAD was not standardized and "who knows when it will be?".
>> Well, it is standardized now (RFC 4429) so I don't see any technical reason
>> why it should not be used.

Rajeev:> the initial justification is not the reason why we are using
UNA/NAACK. UNA is not a new message, it's short for Unsolicited Neighbor
Advertisement as in RFC 2461. 4068bis is specifying that such a message be
sent upon attaching to NAR. NAACK is an option in RA.

We had a long discussion on the topic after 4068 was published on this. You
should really consult the ML before jumping into things here. Briefly,
4068bis can be implemented w/o ODAD, which is specifying extensions to 2461
and 2462. Folks have implemented 4068 (e.g., fmipv6.org, Tarzan) and
provided input, which is taken into consideration in 4068bis.  Finally, if
you would like to use ODAD, you can do that with 4068bis (please read the
draft Syam Madanapalli and I wrote on using fmip with dna a while ago).

>>Is there one? Perhaps one reason is that as described in
>> Section 6.4.6, FMIP has a lot of different conditions involving what to do
>> if there is an address collison. Since the draft admits in Section 5.5
>> that collisions are a low probability event, what is the point of including
>> that level of complexity?

Rajeev:> From Section 6.4.6, I assume you are referring to the Status values
1,2 and 3 in NAACK. These values are not there because of address collision
alone. Example: a MN has configured NCoA using the aggregate prefix
advertised in PrRtAdv, but the link uses per-MN (/64) prefix. (See a draft
by Frank Xia on ptp links). In this case, the base spec can support an NCoA
using the per-MN prefix in the RA using NAACK (Status value 2 in NAACK).

The text "The NAR responds to UNA with the NAACK option to notify the MN
to use a different NCoA if there is address collision." needs to be revised
to reflect the above.

>>FMIP is an optimization, and the only requirement >> is that correctness be
>>maintained if FMIP fails (see comments below about
>> delivery of packets to the wrong node if a duplicate occurs during
>> predictive handover, which would violate correctness). My suggestion is to
>> drop UNA and NAACK now before the IESG issues a DISCUSS on it, and use
>> ODAD instead.

Rajeev:> I don't know if it has crossed your thinking or not, but ODAD does
not specify what to do if there is a collision. In a nutshell, it is
specifying how to issue an NS and an RS with a tentative address. _We_ are
concerned about getting packets from the PAR, which is on a different
subnet, to the current location of the MN. We do some obvious rudimentary
checking at NAR while processing the UNA message, just as in 2461, _and_
report the outcome in NAACK _when_ necessary.

>> 
>> 2) In several places, the draft mentions the NAR "assigning" an NCoA for
>> the MN. As far as I know, there are only five standardized ways for a node to
>> get an IPv6 address: 1) manual configuration (deprecated) 2) address
>> autoconfiguration 3) DHCP 4) IPCP for point to point links 5) Assignment
>> by a VPN gateway in an IKE exchange. With the exception of 4), none of these
>> involve the access router "assigning" an address. So the discussion in
>> Section 5.5 Paragraph 3 and mention in a few other places about how an
>> access router might maintain a pool of addresses and assign them is and
>> really should be outside of the scope of this draft, since I don't believe
>> the purpose of this draft is or should be to define a new standard of how
>> a node obtains an IP address.

Rajeev:> I read Section 5.5 again. As far as I could tell, the intent is
_not_ to specify _how_ an AR could maintain a pool of conflict-free
addresses. But to qualitatively explain what happens _when_ an AR maintains
such a pool. So, I don't see where we are defining a new method for an AR to
come up with a pool of addresses.

>> Given the way the protocol works, there may be
>> in some cases a need for the NAR to obtain an address on behalf of the
>> mobile node, for example, if the access network uses DHCP and allows
>> predictive handover, the NAR may need to obtain the address to remove the
>> need for DHCP signaling on the new link before the MN can use the address.
>> I think the draft should be phrased so that in cases like this, the access
>> router is expected to proxy the address. RFC 2461/2462 include the concept

Rajeev:> an AR has an address that it can offer to a MN. How it has got it,
what it does in a specific deployment scenario are not specified here.

If you have better text, please suggest. I will be glad to look into it and
incorporate it.

>> of an address proxy (though I don't know off the top of my head if DHCP
>> allows it). Again, this point looks to me like DISCUSS bait for the ISEG,
>> so why not fix it now rather than hold up the draft for another year?
>> 

Rajeev:> Well, let's just put our minds here on how to move forward with the
protocol than holding ourselves against the "baits".

>> 3) Section 8 is missing an important case: the PrRtAdv. There is a
>> possible attack whereby the MN issues a PrRtSol and an attacker replies with
>> a PrRtAdv containing a bogus router connected to a bogus AP. The MN hands
>> over and its traffic is stolen. Or, even worse, in network initiate handover,
>> the attacker issues a PrRtAdv with code 1 causing the MN to immediately
>> hand over to the bogus router. The solution is to require that the PrRtAdv
>> have a source address that is a CGA known to be the router's and that the
>> message contain a CGA option with the router's certified public key. The MN
>> must have the router's certificate and check that the key is correct. The
>> reverse case - that of the PrRtSol - isn't a problem since this message is
>> just requesting information.

Rajeev:> the protocol inherits the weaknesses of ND. The scenarios you
describe above involve a compromised router and a compromised link between
the MN and the router.

I can mention this in Section 8.

>> Editorial comments:
>> 
>> Section 2, FNA definition - this should be removed, or moved to a note at
>> the end outlining differences between the proposed standard and RFC 4068.

I will see how best to include it.

>> 
>> Section 3.1 paragraph 6 -
>> 
>> Section 3.1 paragraph 7 - "The NAR can also rely on its trust relationship
>> with the PAR before providing forwarding support for the MN"
>> Section 8 says nothing about the requirements for a trust relationship
>> between the PAR and the NAR. It should be added there that they MUST use
>> IPsec ESP auth and SHOULD use IPsec ESP encryption if the traffic goes
>> over a public network where confidentiality is at risk.
>> 

Ok.

>> Section 3.1 paragraph 7 - last sentence. I would add after this "although
>> the details about how to combine these operations with HI/HAcK are out of
>> scope of this document".

Sorry, which sentence are you referring to?

>> 
>> Section 3.2, paragraph 2: This points up a general problem. The terms
>> "predictive" and "reactive" handover are not introduced until around Fig.
>> 2 and 3. These terms should be added to the terminology section and used
>> earlier, rather than cumbersome phraseology about "when the FBU is sent
>> from the previous link", etc.
>> 
>> Section 4, first point 4: Again, introducing the term "neighborhood
>> discovery" and using it earlier w.r.t. operations by the MN involving
>> PrRtSol/PrRtAdv would improve the readability of the text.
>> 

Ok, good point.

>> Section 4, second paragraph after second numbered list: "MN must use
>> it" >> "MN MUST use it". In general, the text needs closer attention to RFC
>> 2119 language, there are other cases where SHOULD be necessary.
>> 

I will see; at the same time, I don't wish to overuse it :-)

>> Section 4, third point 2: I believe that at least the solicited node join
>> will involve MLD (typically implementations do the all-nodes join
>> without requring signaling).
>> 
>> Section 5.3, paragraph 2: Why distinguish between an address and a prefix?
>> An address is basically a /128. If the NAR returns a /128, then the MN
>> uses it as an address, if it returns a /64, then it uses it as a prefix. In
>> fact, the two options could be merged, simplifying the protocol.
>> 

No, PAR provides both NAR's IP address and an NCoA for the MN to use.

>> Section 5.5: As I mentioned above, I found this entire section problematic.
>> Particularly problematic is the discussion of what happens if the NAR
>> doesn't confirm the address and there is a node on the link with a
>> duplicate but the node's IP to link address binding isn't in the neighbor
>> cache of the NAR because it timed out. The possibility of tunneled packets
>> going to the wrong node is incorrect operation. This means that if predictive
>> handover is used, the NAR MUST confirm that the NCoA isn't a duplicate, i.e.
>> this is a requirement of the protocol in order to ensure correct operation.

Where this is a concern, noting that it is highly improbable, use HI and
Hack, so that NAR can proxy the address until UNA is received. Description
under bullet 1 says just that.

>> Most of the rest of this section involves cases that are handled if ODAD is
>> used.

Again, we and ODAD work under the assumption that collision probability is
miniscule. ODAD does not specify recovery, but has some text showing how
recovery is possible. I have done the same here (i.e., illustrate how
recovery happens when using the protocol _if_ a collision happens.

>> 
>> Section 5.6, paragraph 1: "moves between the same two access points" ->
>> "moves between an access point in one subnet to another then back
>> again" If the two access points are in the same subnet, the MN is unlikely to
>> see any change in its IP subnet.
>> 

Right.

>> Section 5.6, paragraph 3: one issue here is the lifetime of the
>> handover key. Regardless of how it is established, it may not be valid when
>> the MN moves back onto the PAR. Making the key lifetime equivalent to the
>> tunnel lifetime should handle this. After the tunnel is gone, the security
>> association isn't needed anyway.
>> 

So, we should state the lifetime of the key somewhere else, right?

>> Section 6.1.1 (and the rest of the ICPM messages) Should the
>> Experimental Mobility Protocol type code continue to be used or should a new
>>code be obtained? After all, the draft will be going to proposed standard.
>> 

I don't know. Perhaps we should establish a new registry?

>> Section 6.2 all messages: A hop limit of 255 won't work on the inter-router
>> messges. This is used in ND to detect if the message came from an
>> on-link node, but the routers may be multiple hops away.
>> 

Ah, it's a concern for HI and Hack I guess.

>> Section 6.2.2: The number of error codes seems excessive to me. The
>> following text really doesn't call for different action for codes 1,
>> 2, 3, or 4. If there are different actions, then they should be described.
>> If not, then how about reducing the number of codes?
>>

Let me look into it.

>> Section 6.3.2: As I understand it (and as depicted in Fig. 2), the
>> FBAcK is sent to both the PCoA and NCoA in predictive handover, yet the
>> destination address here is listed as the NCoA.
>> 

Ok, will fix.

>> Section 6.4.1 and 6.4.2: How about merging these into a single option
>> that could be a /128?
>> 

I have thought about it earlier.. The MN needs NAR's IP address and the
prefix on the new link. When NAR's IP address is derived from the same
prefix that's advertised on-link, the prefix information option need not be
present. The spec says it under 6.1.2 - New Router Prefix Info Option.
When they are not (for whatever reason), the MN needs both.

>> Section 6.4.3: How about using the IANA Layer 2 Access Technology
>> Identifier Registry to structure the LLA field? This would allow standardized
>> handover between different wireless link types, like 802.11 and 802.16. This
>> registry is active, and recently received some assignments for EV-DO. Given
>> the current description, it would be difficult to do this in a
>> standardized
>> manner.
>>

Okay, that will be good. Do you have a pointer to the registry handy?

>> Section 6.4.5: Regarding the SPI, I think it isn't enough to reserve a
>> single SPI for SEND keys, because it won't support algorithm agility.
>> I think we can let SEND keys negotiate the SPI, we need to discuss this.
>> 

Our previous discussion seems to concluded that signaling algorithm agility
should be an option in the protocol that establishes the SA. FBU only makes
use of the SA, so SPI should be enough to point out what algorithm to use.

>> Section 8: As mentioned, this needs to specify the inter-router SA and
>> also that the PrRtAdv needs to use SEND.
>> 

Ok.

>> Section 9: As mentioned, if the Experimental Mobility Protocol type is
>> not used, this needs to mention what should be.
>> 

Right.

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

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 19 Jul 2007 14:58:41 -0700

(Vijay, can you forward if the list doesn't get this? Thnx.)

jak>> Yes, I remember the discussion well. I was not in agreement with using 
something other than ODAD then and I am not in agreement with it now. If 
there is a simple way to reduce the amount of complexity by using ODAD 
(which, from the looks of it, Syam has documented) then I think it should be 
made part of the base protocol. The less complexity, the less likely 
something will go wrong and the easier it will be to implement. Also, having 
FMIP well-integrated into well known and widely used link configuration 
protocols will make it easier to understand.

jak>> Note that I am *not* proposing that DNA be made part of the base 
protocol, clearly that can be optional. But ODAD and DNA are two different 
protocols.

jak>> Is there some deployment reason why the PrRtAdv would advertise 
something other than what the link actually supports? Shouldn't a per-MN 
prefix come back from the NAR via the HAcK if the MN is configuring to the 
new link and the new link supports per MN prefixes? I think it should be 
part of the protocol that if the link uses per-MN prefixes, these should be 
advertised in the PrRtAdv. I mentioned something about some tweaks to the 
currently documented mechanism to make that easier below.

jak>> The statistical probability of an address collison in the absence of a 
deliberate attack is lower than the probability that a frame is dropped on 
wired ethernet. So that means, for 802.11 for example where the probability 
of droppage is even higher, the probability that the UNA or NAAK gets 
dropped is higher than the probability of a collision, meaning the MN won't 
find out about it. Putting all that additional mechanism in for such a low 
probability event doesn't make sense to me.

jak>> If an attack occurs, then the UNA isn't going to help, since the 
attacker can watch for and respond to the UNA, which is multicast. The 
solution for that if ODAD is used is to use a CGA and sign the ODAD NA.

jak>> Anyway, like I said, we have discussed this already and I doubt 
whether you are likely to change your position, and I am not about to change 
mine (namely "simpler is better"). If this remains in the document when it 
is submitted to the IESG, I'd like the IESG document writeup to indicate 
that there was disagreement in the WG about UNA/NAACK (Vijay, please note).

jak>> But the text does, in fact, discuss having an AR maintain such a pool. 
This is a basic change to the fundamental local link architecture. The 
Neighbor Cache in 2461 is soft state. What this is saying is to make that 
hard state, absent a careful consideration of the implications and possible 
ways to mitigate the drawbacks of hard state. Not such a good idea, IMO.

jak>> Then why not simply say that? Why not say "There are a variety of ways 
the NAR can proxy an address for the MN on the new link. The details of how 
that is done are outside the bounds of this specification."

jak>> :-)

jak>> OK.

jak>> OK.

Ok.

jak>>  Ah, sorry, I got the wrong sentence. This one:

   "Finally, the access
    routers could transfer network-resident contexts, such as access
    control, QoS, header compression, in conjunction with handover."

jak>> I'd suggest:

   "Finally, the access
    routers could transfer network-resident contexts, such as access
    control, QoS, header compression, in conjunction with handover,
     although the details about how to combine these operations
     with HI/HAck are out of scope of this document."

Ok, good point.

jak>> It's not a question of overuse. When doing interoperability testing, 
features marked MUST become "required to implement" and failure of 
interoperability on those features means that a particular protocol 
implementation fails conformance to the standard. SHOULD and MAY are 
"optional to implement" but if implemented, they should be interoperable. So 
consideration needs to be made about what features are necessary to be 
required to implement (i.e. the protocol fails to operate correctly without 
them) and which are optional (i.e. the protocol works less well or is not 
applicable in some cases). In the particular case cited, it seems to me that 
the protocol would, in fact, fail to operate correctly unless the feature 
was properly implemented.

jak>> I'm not sure I understand. Why does it matter if the option has NAR's 
address or an NCoA, if it is marked as a /128 (see more below)?

jak>> Right, but the paragraph before that implies that one could deploy the 
protocol for predictive handover *without* using HI/HAcK to confirm the 
NCoA. I think this needs to be changed to say that this is not allowed, that 
is, for correct operation of the protocol, all predictive NCoA configuration 
requires that the NAR confirm uniqueness and proxy the address until the MN 
shows up on the new link.

jak>> See above. And, as I mentioned, FMIP is an optimization. Given the 
minuscule chance that address uniqueness fails, the MN can simply forgo the 
optimization. The recovery operation is complex and unnecessary, IMO.

Right.

jak>> I'd just say that in order to prevent a problem with the key lifetime, 
the lifetimes SHOULD be the same. I think the key provisioning drafts talk 
about how to establish the lifetime for the individual key provisioning 
protocols.

jak>. Hmm. I think you need to check with IANA about this. I don't think a 
new registry is necessary. I don't really think it matters if the same 
number is used, but it probably ought not to be called experimental in that 
case. Maybe Jari can provide some guidance.

jak>> Right. HI and HAcK need to have something other than 255.

Let me look into it.

jak>> OK.

Ok, will fix.

jak>> I'm not sure I understand the issue. What's the problem with sending 
both? I'm not saying to merge the use, I'm saying to merge the Option types 
so there is one option that can be either a prefix or a full address, 
depending on the size. If the MN needs a prefix and an address, then two 
instance of the option would be sent. It could look exactly like the current 
IP address option. Whether or not it's a prefix should be apparent from 
whether or not there are any one's in the last 128 - n (or 128 - n - k if 
the prefix is shorter than a full subnet prefix) bits, where n is the value 
of the Prefix Size field. Alternatively, an additional field could be added 
to specify the number of valid bits.

jak>> Yes its:

http://www.iana.org/assignments/card-parameters

jak>> Hmm, well, the SEND key is named by the CGA and if algorithm agility 
is part of the key provisioning negotiation then I suppose you are right. 
The key will have its prenegotiated algorithm type recorded along with the 
name.

Ok.

Right.

-Rajeev
--

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Jul 2007 12:20:05 -0700

> protocols will make it easier to understand.

I am guessing that your impression of "complexity" is stemming primarily
from Section 5.5. What if I move most of that expository text to the
appendix and replace it with some text that in essence says "if NAR detects
an entry in NCE for NCoA, send an RA with NAACK"? Because, other than that,
we are not doing anything else.

Note that we a) got rid of FBU encapsulation guideline, and b) deprecated
FNA. 

> protocol, clearly that can be optional. But ODAD and DNA are two different

I understand that clearly.

> currently documented mechanism to make that easier below.

Advertising per-MN prefixes is one way to do it. However, this requires the
routers to keep track of prefix for each MN.
My point is the base spec can be used to accomplish what you need in this
case. We don not want to specify exactly how this is done, since it is (like
others) deployment specific.

> probability event doesn't make sense to me.

Which additional mechanism? Sending NAACK?
We need it even when not reporting any collision case as I explained above.
(Status values 2 in NAACK).

As I mentioned above, I can move much of the text in 5.5 to appendix.

> solution for that if ODAD is used is to use a CGA and sign the ODAD NA.

I think you told me that CGA works for NA. So, the same should work for UNA
as well; UNA can be unicast to the router.

> that there was disagreement in the WG about UNA/NAACK (Vijay, please note).

Ahem.. It's what the WG wants. For instance, fmipv6.org folks who
implemented 4068 didn't want to implement another protocol. Please go back
to archives and take a look.

> ways to mitigate the drawbacks of hard state. Not such a good idea, IMO.

Well, I guess I will read again. You could also help me by pointing out the
text where it gives this impression, and suggest alternate text.

I didn't follow the stuff about soft state hard state. Last I remember, MIP4
has visitor list entry, which stays longer ("hard state"). That might be
another thread..

Ok.

Ok.

> was properly implemented.

I understand 2119 terms.

> shows up on the new link.

It is clear that HI/Hack exchange is needed where the collision is a
concern. Where it is not, the concern is the same as in ODAD; you could send
a BU with a tentative address and traffic could go to an unsuspecting node
when using ODAD, and there are no preventive mechanisms. It is considered
such a case is unlikely however. The same applies with 4068bis.
  
> optimization. The recovery operation is complex and unnecessary, IMO.

As I mentioned above, the recovery operation is send a NAACK in an RA. We
cannot get rid of NAACK because NAACK can be used to provide an address to
the MN (i.e, whatever NAR has proxied earlier on). We can move most of the
text in 5.5 to appendix.

Ok.

> to specify the number of valid bits.

I think I agree with you. We could use a different Option-Code for Prefix to
simplify processing.

> http://www.iana.org/assignments/card-parameters

Thanks.

Ok.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Jul 2007 15:13:50 -0700

jak>> The issue is also introducing additional functionality where there is 
already a standardized protocol that supports the functionality. Section 3.2 
in RFC 1958 is relevent here, as well as Section 3.5.

jak>> Don't the routers need to do that anyway if they hand out per-MN 
prefixes?

jak>> Yes.

jak>> Hmm, well status value 2 is essentially involving the router in 
address configuration, since NAACK is received when the MN is on the new 
link. Like I said in the original review, I don't believe this draft should 
be standardizing a new way to do address configuration. If the node 
experiences a duplicate, it should back off and reconfigure the address 
using DHCP or addr autoconf (it won't get a duplicate if IPCP is used). Of 
course, it will probably lose some of the optimization but since the 
statistical probability of an address clash happening spontaneously is very 
low, the optimization should fail very infrequently.

jak>> Yes, it would work for UNA.

jak>> Right, but the whole point of having that field in the document 
writeup is for "minority report" cases. I don't intend to push this issue 
beyond the IESG review of the document. I won't appeal it if the IESG 
decides to accept the UNA/NAACK. However, I do want to make clear to them 
that there are some people (and I wasn't the only one during the original 
discussion) who don't agree with this design, and that there are 
alternatives based on existing standards.

jak>> Probably another thread. Regarding the text, I'd suggest the 
following. Change this:

    "In deployments where NAR does not have means to assess and inform
    the uniqueness of NCoA or cannot provide a duplicate-free address
    using HI and HAck exchange, the following scenarios are possible,
    although highly improbable considering that the probability of a
    random address collision is very small."

jak>> To this:

     "Use of HI/HAck to confirm address uniqueness is REQUIRED in
       all cases of predictive handover. Failure to confirm address 
uniqueness
       can lead to the following pathalogical scenerios:"

jak>> I'm saying that the HI/HAcK exchange should be "required to use" in 
all cases of predictive handover, to avoid the potential for a clash. In the 
case of predictive handover, there's no reason why an address clash should 
ever happen because the NAR can proxy the address until the MN gets to the 
new link.

jak>> See above. I still would prefer removing UNA/NAACK and using existing 
standardized IETF mechanisms.

jak>> OK

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 20 Jul 2007 19:52:02 -0700

Ok, my take on this as of now:

1) I failed to convince you that UNA is a standard message. (ODAD uses it!)
2) NAACK is required for reasons other than address collision.
3) Making Section 5.5 part of appendix is not good enough.

I don't see why we need to implement another protocol here.. Despite the
fact that folks who have implemented it have said they can do it, and that
they don't want to implement ODAD. I cannot force people to use it.

Let's move on.

Thanks for your input on other points; they are useful. I have made note of
them.

-Rajeev