Hi Pascal,
Please see the response in-line. Thanks.
> > If tentative NCE is not recorded, and a multihop DAD request on the
> way,
> > then the second node came in and sent the registration request, if the
> > response of this request arrives earlier than the first request, the
> wrong
> > node gets in and the original request is denied. Also this can induce
> a flood
> > of multihop DAD requests from 6LR to 6LBR by an attacker.
>
> [Pascal]
> I do not find those arguments very convincing:
>
[SC>] The point is that the state is kept for sometime in order to prevent
DOS problems.
In 6lowpan the bandwidth is small and so preventing known DOS problems are
useful.
> - An attacker can claim the same address on the next LR and get the same
> chances to hijack
> - If an attacker has access to the medium, then it can register tons of
> different global addresses from a number of forged mac addresses. If he
has
> access to the geography, then it can simply jam the spectrum.
>
[SC>] The above examples assume that the node gets L2-access because
L2-access is not secure.
But the problem with tentative NCE can appear from a node with secured
L2-access. A node may have a bad implementation and starts sending hundreds
of registration messages that require multihop DAD. If the state is not
kept, the 6LR will be busy processing and forwarding the same request over
and over.
6lowpan-nd assumes that the L2-layer is secure.
> >
> > So, tentative NCE is useful and the implementation can flag this entry
> not to
> > include it in the regular data path.
>
> [Pascal] Which illustrates again the danger of mixing the properties and
> usages of the registration table and the neighbor cache.
> The state that you are talking about (PENDING_VALIDATION_BY_LBR) does not
> exist in the classical Neighbor Cache FSM.
[SC>]
Classical Neighbor Cache does not do Route-over topology either nor
does it support
Multi-hop DAD concept.
Good that you are talking about the PENDING_VALIDATION state; it is needed.
But, the draft is flexible about how to implement it.
An implementation may keep the classical implementation intact and add a new
table for tentative_NCEs so that the original NCE-table is dedicated to the
fastpath.
As for timing out of existing NCEs - it is also done in the existing
classical NCE. But in case of multihop, the operation is different. Again,
if it makes sense the implementation may maintain a separate data structure
pointer from the NCE flagged for multi-hop verification.
In case of MIP6, the BCE is absolutely needed as the destination was indeed
a neighbor who has changed its IP-address and is no longer a neighbor. So,
I don't think the tentative NCE is exactly the same as BCE in MIP6.
Regards,
-Samita
> It makes a sense to me to keep the table and the cache abstractly separate
-
> exactly like we did with MIPv6 and the BCE -, because though the data have
a
> lot in common, the lifecycles and operations are really different.
>
> >
> > Thanks,
> > -Samita
> >
> > > It would make the ND process much simpler and clean.
> > >
> > > Br,
> > > Mads
> > >
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]] On
> > > Behalf Of Samita Chakrabarti
> > > Sent: 7. oktober 2010 01:19
> > > To: 'Colin O'Flynn'; [email protected]
> > > Subject: Re: [6lowpan] 6lowpan-nd neighbour table collision
> > >
> > > Hi Colin,
> > >
> > > I'd assume that temporary NCE will not be used for data sending. I
> > > think
> > the
> > > purpose of creating temporary NCE is to prevent processing the
> > > duplicate request when the previous one is under flight to/from the
> 6LBR.
> > >
> > > I'd add a flag to the NCE marking it as temporary and will not use
> for
> > > sending data or determining nexthop resolution. Thus a little
> > > modification is needed in NCE-lookup code in the kernel and the ND
> > > response messages could use the SLLAO for MAC-address and turn the
> > > temporary entry to permanent entry by clearing the flag after DAD
> > verification.
> > >
> > > Erik and Zach, do you have similar view on the temporary NCE? Looks
> > > like
> > we
> > > need to check the document to see if there is enough clarification.
> > >
> > > Thanks,
> > > -Samita
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email protected] [mailto:[email protected]]
> > On
> > > > Behalf Of Colin O'Flynn
> > > > Sent: Wednesday, October 06, 2010 9:38 AM
> > > > To: [email protected]
> > > > Subject: [6lowpan] 6lowpan-nd neighbour table collision
> > > >
> > > > Hello,
> > > >
> > > > I had a question / possible problem with 6lowpan-nd and would
> > > > appreciate clarification from the 6lowpan-nd authors or others
> > > familiar with it.
> > > >
> > > > Assume you have the following network, for simplicity I've used
> all
> > > fe80::
> > > > addresses. I'll bring a hypothetical network up here:
> > > >
> > > > Step #1: Initial State
> > > >
> > > > Border Router: fe80::33:44
> > > > |
> > > > Router 1: fe80::11:22
> > > > |
> > > > Router 2: fe80::55:66
> > > >
> > > > Consider router 2. It's neighbor cache (NC) will have the
> following:
> > > >
> > > > NC:
> > > > fe80::11:22
> > > >
> > > >
> > > > As it cannot talk to fe80::33:44 directly it should not be present
> > > > in the NC.
> > > >
> > > > Step #2: New Device attempts to join with address fe80::33:44
> > > >
> > > > Border Router: fe80::33:44
> > > > |
> > > > Router 1: fe80::11:22
> > > > |
> > > > Router 2: fe80::55:66
> > > > |
> > > > New Device: fe80::33:44
> > > >
> > > > Router 2's state:
> > > > NC:
> > > > fe80::11:22
> > > > fe80::33:44 (temporary NCE for 6lowpan-ND)
> > > >
> > > > According to 6lowpan-nd, it will check it's NC and its own address
> > > > for
> > >
> > > > collisions. Finding none, it will now attempt multi-hop ND after
> > > > adding
> > > the
> > > > temporary NCE.
> > > >
> > > > The ABR is address fe80::33:44 so it will now send a multihop ND
> > > message.
> > > > The regular IPv6 sending algorithm will first search the NC for
> > > connectivity
> > > > before sending through the default router (fe80::11:22).
> > > >
> > > > However - the NC now has an entry for fe80::33:44 so it will
> attempt
> > > > to
> > > send
> > > > directly to this device. Indeed all connectivity for the ABR will
> be
> > > broken
> > > > until that temporary NCE times out.
> > > >
> > > > If this is correct I can see two possible solutions:
> > > >
> > > > #1) Update 6lowpan-nd to say that you check the joining node's
> > > > address
> > >
> > > > is not in the NC OR the ABR you will be performing multi-hop ND
> with.
> > > > It doesn't matter if the address is of some intermediate node as
> it
> > > > will
> > > still
> > > > result in the default router being used, you just need to check
> > > > against
> > > the
> > > > ABR.
> > > >
> > > > #2) Send from a known-unique address and carry the address in the
> > > > ARO,
> > >
> > > > but
> > > I
> > > > think this won't be accepted still...
> > > >
> > > > Regards,
> > > >
> > > > -Colin
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > 6lowpan mailing list
> > > > [email protected]
> > > > https://www.ietf.org/mailman/listinfo/6lowpan
> > >
> > >
> > >
> > > _______________________________________________
> > > 6lowpan mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/6lowpan
> > >
> >
> >
> >
> > _______________________________________________
> > 6lowpan mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
