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

From: Rajeev Koodli <[email-masked]>
Date: Mon, 05 Nov 2007 12:40:35 -0700

Hi Jari,

I think I am okay with most of the following. There is some additional
discussion about using UNA; see below.

On 10/30/07 3:00 PM, "ext Jari Arkko" <[email-masked]> wrote:

>> In general, the protocol does not require changes to other protocols, their
>> timing etc, including MIP6.
>>   
> 
> This is good, but I think it should be explicitly stated.
> 

Ok.

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

Okay. I can look into it and add some text.

>> 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
>>   
> 
> We need text about this in the draft.
> 

Okay. 

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

Okay.

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

A file such as fmip6.h may be implemented to maintain handover state for
each node. See for instance
http://fmipv6.cvs.sourceforge.net/fmipv6/fmipv6/include and other related
files. AFAIK, you don't need to make changes to the ND data structures.

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

Ok.

>> 
>> Isn't this deployment-specific? The protocol is not specifying key
>> 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.

Ok.

> 
> (You may want to specify an optional one for interoperability
> purposes, however. This should not be hard. But I'll let you
> decide.)
> 
 
Ok.

>> 
>> It does not. Hence it sends the UNA message first which has its LLA and the
>> NCoA. 
>>   
> 
> Ok. I would suggest adding some words to the document
> about this.
> 

Ok. 

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

NCE is Neighbor Cache Entry. Yes, it is a cache and is not at all guaranteed
to contain all addresses active on the link. The purpose is not to cover all
the addresses, but _if_ there is an address in NCE, it can detect it.

>> We assume that HI and Hack are between trustworthy routers which have SA
>> between them. 
>>   
> 
> Ok. You should say so.

Ok.

>> 
>> 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.
>>   
> 
> But an MLD snooping switch would presumably want to know
> that a host has changed port, no?

It may, but that's not something this protocol explicitly supports. May be
we could specify it for such devices in a different spec, if there is
interest..

>> 
>> 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?
>>   
> 
> 
> The question is, does *your* document somehow change the required or
> desired behaviour of nodes for sending unsolicited NAs?

No. It specifies that a UNA be sent upon changing a subnet for nodes that
implement the protocol.

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

Ok. 

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

The NCoA is looked up with the LLA (supplied in UNA) by the NAR. The same
LLA is also supplied in the HI message. So, NAR recognizes that it belongs
to the MN in question.

>> 
>> 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.
>>   
> 
> If so, that needs to be specified and clearly marked
> as a requirement.
> 

Ok.

>> 
>> Yes, just to maintain the simplicity of operation. We _could_ state that it
>> MAY be omitted.
>>   
> 
> I would recommend not allowing freedom, simply requiring the option
> if the address is not the same, otherwise source address applies.
> 

OK. 

> 
> Additional behaviour (NAACK) may be fine.
> 

Ok.

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

The only issue as I see it is the recommendation to create an entry in STALE
state if none exists. This was done so that the arriving packets do not have
to invoke address resolution and then forward packets. If this turns out to
be an issue, I am willing to reconsider the recommendation.

>>> 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.
>>   
> 
> But as discussed earlier, there is no requirement that all nodes
> (particular ones that don't do fmip) are in the cache.
> 

Yes, the protocol is not assuming that all the node addresses will be in the
cache. IF there is an entry, the NAR can detect it.

>>> 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.
>>   
> 
> RFC 4861 allows UNAs with both O=0 and O=1. So I think my
> question still stands.
> 

We are not trying to differentiate the two UNAs per se. Only trying to send
an RA if it turns out that an NCE already exists.

Indeed both 2461 and 4861 allow any node to set O=0.

Let's consider the legacy node. If it sends UNA with O=0, the receiving node
only makes a state change (from REACHABLE to STALE) if the NCE is in
REACHABLE state and the supplied LLA is different. For INCOMPLETE state, the
O flag is ignored, state changes to STALE (with S=0) and the LLA is
recorded. 

Now consider the MN. It's state at the router cannot be in REACHABLE state.
It can only be in INCOMPLETE state or there is no state. In the INCOMPLETE
state, there is no LLA in the NCE. Hence the router cannot detect that there
is already an entry.

In sum, there is no way to detect that an NCE exists in INCOMPLETE state
regardless of who sends the UNA. So, the NAR does not send an RA.

>> 
>> If the LLA in UNA was from another radio link than the one to which the MN
>> (and the NAR) is currently attached to.
>>   
> 
> Ok, but this needs to be spelled out.
> 

Ok.

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

Ok. 

>> 
>> CoA Test is not done with the HA.
>> 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).
> 

Ok. Let me see if I can revise the text.

>> 
>> 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.
>>   
> 
> Actually, the necessary details are in the companion document. Please
> reword this text to make it clearer that this is the case.
> 

Ok. 

>>> 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.
>>   
> 
> 
> I'm sorry, I do not remember anything about this particular issue.
> I would recommend including guidance about the expected
> configuration.
> 

Ok.

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

> Jari

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Nov 2007 15:58:53 +0200

Rajeev,

We're getting closer, I think. Please remember the drafts deadline
next Monday; if you can get at least partially updated spec out
by then it would help us to do other reviews etc when reviewers
don't have to ask the same questions again.

The two main remaining issues appear to be cache/DAD/UNA handling
and MLD handling.

> files. AFAIK, you don't need to make changes to the ND data structures.

Ok. But still, I think it would be beneficial to describe what
the other data structures are that you need. (At a conceptual
level.)

> we could specify it for such devices in a different spec, if there is

I don't think that is the way we should do this. Existing switches, router
behavior, ND, MLD snooping --- all of that should be taken as a given,
and you should generally be able to live with it, unless there is a
significant
reason to not to.

The high level question in this case is who dictates the ND/DNA/DAD/MLD/etc
behaviour of the FMIP mobile node? This spec? Someone else?

I would say that you should refer to other specifications where
possible. E.g.,
this specification does not change anything in the requirements of 4861
about what ND should do about new links. But where that is not the case,
you should deal with it.

>> explicitly be called out. (..., as specified in RFC XXXX Section YY).

Good.

> LLA is also supplied in the HI message. So, NAR recognizes that it belongs

Hmm. How?

Specifically, how does the NAR differentiate between (a) someone has the
same link layer address and just happened to send UNA and (b) the same
mobile node already moved here?

Or are you saying that you don't need to distinguish these from
each other? If yes, can you explain why?

> be an issue, I am willing to reconsider the recommendation.

Ok, good.

> cache. IF there is an entry, the NAR can detect it.

So this means that the protocol makes address allocation
decisions with an algorithm that has a failure mode where
it does not detect that an address was already in use?
Wouldn't this be bad?

Ok.

> regardless of who sends the UNA. So, the NAR does not send an RA.

So, in conclusion, will you update the spec with regards to
what it does or does not differently from plain old ND?
(As defined in 4861.)

Jari

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 15 Nov 2007 10:17:59 -0800

> the other data structures are that you need. (At a conceptual

I will see how to keep this at a high level.

> about what ND should do about new links. But where that is not the case,

Looks like having a section on "Implications" would be useful. I have
perhaps taken for granted that the existing devices, other than the router
and the MN, do not have to do anything. (This is supported by a few
implementations). 

> mobile node already moved here?

An existing node on the link typically sends the UNA with O=1 when it wishes
to update the LLA among the other nodes. MN can only send it with O=0.
2861/2461 both allow O=0, but see the discussion below.

> it does not detect that an address was already in use?

Even if the address is not in NCE, the failure mode you are referring to is
1 in 2^64. 

Nevertheless, the protocol clearly states that it SHOULD only be used where
the probability of collision is extremely low.

The protocol also allows for the scenario where conflict-free addresses are
maintained (by techniques not specified by the protocol) by the router and
handed out to the MNs.

Ok.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Sun, 18 Nov 2007 18:01:17 -0800

Hi Jari,

> don't have to ask the same questions again.

I have submitted a revised version taking most of the input into
consideration. See Change Log for the major parts.

A remaining issue is how to include a code for NETLMM case. It is more
complicated than I thought since it depends on what assumptions we can make.
Is the MN running FMIP even if not running MIP? Anyway, we can address it in
the next version.

-Rajeev