Subject: [Mipshop] Possible Solution to Duplicate Problem?

From: "James Kempf" <[email-masked]>
Date: Wed, 24 Aug 2005 15:35:56 -0700

MIP4 requires the FA to maintain an ARP cache entry until a MN leaves the 
vistor list. One possible solution to the duplicate problem for FMIP might 
be to require a FMIPv6 router to maintain a NCE until the MN signals FBU. 
This would allow the NAR to provide the PAR with a definitive indication 
whether the address is duplicate, so the PAR could avoid sending packets if 
so. Downside is, what if the MN crashes? A possible compromise is to set the 
NCE timeout to the expected time between handovers plus perhaps a standard 
deviation or so (for cases where somebody comes home and their cell phone 
goes into dormant mode overnight, this might be a long time).

Comments?

            jak 

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

---

From: Emil Ivov <[email-masked]>
Date: Thu, 25 Aug 2005 02:02:15 +0200

> so. 

I personally like that as it's really quite a light solution.

> Downside is, what if the MN crashes? A possible compromise is to set the 

Well I've a actually have a few questions, should anyone care to answer:

Could the presence of non FMIP nodes be an issue? If removal from the 
NCache is triggerred by an FBU what happens to nodes that don't have 
FMIP and therefore don't send an FBU?

And how would those actually get into an AR's cache? First thing that 
comes to mind is - they'll get there when they do their DAD.Then what if 
the FMIP-AR is not the outmost router and it doesn't see the DAD NDisc 
packets (is that possible and should it be taken into account at all?).

Once such a (nonFMIP) node is in ARs cache, how does it get out? As you 
suggest simply timeouting entries might not be enough. Could verifying 
their presence be an option? (i.e. could a large number of such 
verifications lead to saturation)?

10x
Emil

---

From: Greg Daley <[email-masked]>
Date: Thu, 25 Aug 2005 15:21:28 +1000

Hi James,

James Kempf wrote:
> MIP4 requires the FA to maintain an ARP cache entry until a MN leaves 
> the vistor list. One possible solution to the duplicate problem for FMIP 
> might be to require a FMIPv6 router to maintain a NCE until the MN 
> signals FBU. This would allow the NAR to provide the PAR with a 
> definitive indication whether the address is duplicate, so the PAR could 
> avoid sending packets if so. Downside is, what if the MN crashes? A 
> possible compromise is to set the NCE timeout to the expected time 
> between handovers plus perhaps a standard deviation or so (for cases 
> where somebody comes home and their cell phone goes into dormant mode 
> overnight, this might be a long time).
> 
> Comments?

In general it won't work, since there's no reason an existing
IPv6 node would need to keep or create an state on the router,
in the cases that it:

1) doesn't perform FMIPv6 to get there in the first place.

2) outlives the time the cache entry is kept.

It is the presence of nodes which the router is not
explicitly aware of which prevents it from allocating
addresses which it has not DAD-ed (fully) itself.

This is why DHCPv6 clients need to DAD the address
after allocation.

The only ways I can see are to:

1) prevent address allocation without registration
    - very difficult in IPv6
    - need to switch the autoconf flag off, but this
      doesn't deter manually configured devices.
    - could constrain the link to FMIPv6-only nodes...
      what if prediction fails?

2) force registration of addresses through a particular
    query which all address holder must respond to
    (Only MLD requires this - in a limited way, I'm really
    against address reporting services in general, as they
    break an important advantage of IPv6 over IPv4:
    Attackers can't readily find hosts on a link).

3) Pre test addresses (like AdvanceDAD).

4) Test the address upon arrival on-link (using opti-DAD).

Of these, only opti-DAD is generally applicable.
It's quick to give a usable address to the host, and it
doesn't require additional modifications to routers.

Greg.

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Aug 2005 11:22:19 -0700

> doesn't require additional modifications to routers.

Right but oDAD won't work for predictive handover.

Maybe 3) is the right way to go then.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Aug 2005 11:25:23 -0700

> NCache is triggerred by an FBU what happens to nodes that don't have FMIP 
> and therefore don't send an FBU?
>

See Greg's response on this. I suppose this works in MIP4 because the FA is 
handing out the address, so nobody gets an address on the link unless they 
register with the FA.

> verifications lead to saturation)?

I think the only way to handle duplicate checking for predictive handover is 
pre-DADing the addresses prior to the arrival of the node. It does not have 
to be contiguous with handover, however.

            jak

---

From: Greg Daley <[email-masked]>
Date: Fri, 26 Aug 2005 10:20:42 +1000

Hi James,

oDAD works fine, you just can't confirm the address until
you  arrive. :)

3) is a valid way to go, but won't always be applicable.

If there's stateful allocation (or reservation) of
addresses using DHCPv6 (or something like), then it
makes sense to have an exchange using HI/HAck (or FBU/FBack)
to propose an address, or to have one doled out to the host.
This is regardless of whether the address can be guaranteed
unique on the link.

In this case though, it would be good to distinguish
between "perfect" allocation, and standard allocation
which must be confirmed using oDAD, in the returned
FBAck or HAck.

Greg

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 09:39:48 -0700

What happens if there's a duplicate on the new link, and the PAR starts 
tunneling packets before the MN arrives on the new link?

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Aug 2005 10:00:42 -0700

> tunneling packets before the MN arrives on the new link?

oDAD does not solve this problem. The applicability statement in the 
section on Collision Case clearly says oDAD should only be used where 
the probability of collision is small, which is usually the case with 
uniformly distributed IIDs.

I am having a hard time understanding where we interface with oDAD. It 
does not guarantee that an address is collision-free. Only DAD can 
assure you that. So, we can pick an address using NAR's prefix and get 
NAR to lookup its NCE when processing HI. If there is already an entry 
in NAR's NCE, you know there is a conflict. If not, there _can_ be 
collision, whose probability is the same as it is for oDAD. In such a 
case, FMIP would have initiated a tunnel. With oDAD, you can initiate a 
tunnel by sending BU before DAD completes. So, what is the problem for 
which oDAD is needed here?

About intentional collisions: a MN may visit NAR's link, come back to 
PAR's link, send FBU to PAR binding PCoA to an address on NAR's link and 
never move. It's traffic is redirected to a victim on NAR's link.

-Rajeev

>            jak
> 
> ----- Original Message ----- From: "Greg Daley" 
> <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 10:25:45 -0700

> never move. It's traffic is redirected to a victim on NAR's link.

This is a really nasty attack. The MN need not even move back to the PAR, it 
could move to another link entirely. The PAR and the MN have a security 
association, but the NAR isn't involved, so it is not verifying that the 
nCoA is owned by the MN.

One way I can see to solve this is for the NAR to require SEND and not 
establish an NCE for the MN unless it gets an authenticated CGA in an NA in 
response to the NS from a node on the link. Alternatively, the NAR might 
require a CGA and some authentiation as part of the HI/HAck, if we are going 
to allow the HI/HAck to cause an NCE to be established.

The other way to solve it would be to enforce DHCP assigned addressing. The 
attacker then gets assigned an address on the new link, and so can't spoof 
the address of another node. The router would have to enforce this, however, 
and not route packets to addresses that are not DHCP assigned. This would 
require that the router act as a DHCP server or relay, and record what 
addresses are assigned and what aren't.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Aug 2005 14:12:07 -0700

James Kempf wrote:
>> PAR's link, send FBU to PAR binding PCoA to an address on NAR's link 
>> and never move. It's traffic is redirected to a victim on NAR's link.
>>
> 
> This is a really nasty attack. The MN need not even move back to the 
> PAR, it could move to another link entirely. The PAR and the MN have a 

We can ensure that PAR only processes FBU with PCoA as source IP address 
or NCoA as source IP address (with PCoA as HAO). So off-link attacks are 
avoided.

> establish an NCE for the MN unless it gets an authenticated CGA in an NA 
> in response to the NS from a node on the link. Alternatively, the NAR 
> might require a CGA and some authentiation as part of the HI/HAck, if we 
> are going to allow the HI/HAck to cause an NCE to be established.

SEND is a possibility. However, even with HI and HAck, the attack is 
avoided because we require NAR to proxy NCoA. So, until the MN attaches 
to the new link and sends an unsolicited NA with the same LLA carried in 
HI, NAR will not forward packets to NCoA. So, minimally the MN has to be 
on-link to force redirection to a victim, which is possible  today when 
you allow an address to use when DAD is in progress (e.g., in oDAD case).

-Rajeev

> 
> The other way to solve it would be to enforce DHCP assigned addressing. 
> The attacker then gets assigned an address on the new link, and so can't 
> spoof the address of another node. The router would have to enforce 
> this, however, and not route packets to addresses that are not DHCP 
> assigned. This would require that the router act as a DHCP server or 
> relay, and record what addresses are assigned and what aren't.
> 
>            jak
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 14:23:16 -0700

>> This is a really nasty attack. The MN need not even move back to the PAR, 
>> it could move to another link entirely. The PAR and the MN have a
>

So the MN can put PCoA as the source address even if it sends from another 
link. Ingress filtering will naturally defeat this, but not everybody 
deploys it.

> avoided because we require NAR to proxy NCoA. So, until the MN attaches to 
> the new link and sends an unsolicited NA with the same LLA carried in HI, 
> NAR will not forward packets to NCoA. So, minimally the MN has to be 

What if the MN sends a bogus LLA in the FBU? The NAR sends NS when the first 
tunneled packet arrives, the victim replies NA, and the attack proceeds.

I suppose we could defeat this by requiring the NAR to not forward tunneled, 
buffered packets until there is an unsolicted NA with the same address as in 
the HI. This would inhibit the normal address resolution procedure for those 
packets.

It still seems a kind of weak protection to me. The MN could get on the link 
quickly, send the unsolicted NA with the victim's link address, then get off 
again. Unless the NA is protected by SEND, the NAR can't be sure the sender 
of the NA is the actual owner.

                     jak

---

From: Theodoros Pagtzis <[email-masked]>
Date: Fri, 26 Aug 2005 22:32:37 +0100

Rajeev Koodli wrote:

> never move. It's traffic is redirected to a victim on NAR's link.

right you have just mentioned the inherent problem of FMIPv6 occuring 
during a ping-pong effect. I was well aware of that not as an 
intentional collision (I cannot see intention during a ping-pong unless 
one has a magic screen of PAR and NAR cell (wave) boundaries to do it 
intentionally.

theo

-- 
theo
Nets & Mobile Systems Group
UCL-CS

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Aug 2005 14:32:49 -0700

James Kempf wrote:

> So the MN can put PCoA as the source address even if it sends from 
> another link. Ingress filtering will naturally defeat this, but not 
> everybody deploys it.

Do no more harm.

> 
> What if the MN sends a bogus LLA in the FBU? The NAR sends NS when the 

It doesn't. It is proxying the address.

> first tunneled packet arrives, the victim replies NA, and the attack 
> proceeds.

The MN has to send an unsolicited NA first before NAR forwards packets.

> 
> I suppose we could defeat this by requiring the NAR to not forward 
> tunneled, buffered packets until there is an unsolicted NA with the same 
> address as in the HI. This would inhibit the normal address resolution 
> procedure for those packets.
> 

Right. That's how it is supposed to be already.

> It still seems a kind of weak protection to me. The MN could get on the 
> link quickly, send the unsolicted NA with the victim's link address, 
> then get off again. Unless the NA is protected by SEND, the NAR can't be 
> sure the sender of the NA is the actual owner.
> 

Anything that deals with ND security per se (e.g., whether the MN owns 
the address, LLA is valid etc.), I guess we have to fall back on SEND.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Aug 2005 15:37:42 -0700

Hi Theo,

> one has a magic screen of PAR and NAR cell (wave) boundaries to do it 

intentional because the MN has the intention of causing redirection to a 
known host on the NAR's link.

Hope this clarifies.

Regards,

-Rajeev

---

From: Theodoros Pagtzis <[email-masked]>
Date: Fri, 26 Aug 2005 23:47:15 +0100

Hi Rajeev,

Rajeev Koodli wrote:
>> intentional collision (I cannot see intention during a ping-pong 
>> unless one has a magic screen of PAR and NAR cell (wave) boundaries to 
>> do it intentionally.
>>
> 

ok but this is a redirection attack. How does the collision quialifier 
enter into this?

theo

---

From: Greg Daley <[email-masked]>
Date: Mon, 29 Aug 2005 12:07:29 +1000

Hi James,

> tunneling packets before the MN arrives on the new link?

This is the same as any Optimistic DAD case, where there
is an existing NCE with the AR (in this case nAR), by
an address holder.

In oDAD:

The real address holder will receive packets not destined for it.
The upper layer protocols (typically) will identify that the
upper layer IDs, don't match ongoing sessions, and a TCP reset
or a destination unreachable may be generated, packets being
dropped.

There is some small chance that the packets will be received by the
real-address owner, but that would only occur typically for
new TCP sessions, or datagram applications without sequence number
or source address checks.  Collisions within the TCP sequence window
are quite a low chance - on top of DAD...

Back to FMIPv6 predicition and oDAD:

In this case, we have a datagram application without sequence number
checks: packet tunneling.  It has source address checks though,
and the real address owner should drop the packets.  Even if the
source check fails, then the same behaviour could be expected
as for untunneled collisions.

Please be aware that the destination unreachables can only affect
the interloper's communications with its CNs, and that the extension
of collision would only be for the "fast" prediction time.

Greg