Subject: [6lowpan] source address validation in ND 03

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 May 2009 11:55:10 +0200

The current draft inherits source address validation text from the
backbone router draft that's meant to prevent nodes in the LoWPAN from
using any address as source.

section 7.5. about forwarding by Edge Routers has: 

"

        Upon receiving packets on one of its LoWPAN interfaces, the Edge

        Router checks whether it has a binding for the source address.
If it

        does, then the Edge Router can forward the packet; otherwise,
the

        Edge Router MUST discard the packet.

"

That was fine for a backbone router in a mesh under situation but that
seems to falls short for route over, because in that case the Edge
Router is not necessarily the first hop:

-          How can we be sure that the route over infrastructure will
actually route the packet via the right Edge Router?

-          How can we filter impersonation attacks from within the same
LoWPAN?

So what can we do? 

a)      One way is to tunnel to the edge router. 

Over the tunnel, the Edge router is really the first hop. It can check
that the source address exists but cannot match the LLA. Some credential
like a soft token in the tunnel header could prove that the node is
really himself.

Caveat: that forces all local comm. through the Edge Router and back, so
that's overhead in each packet + overhead in path length.

b)      Another way is to place the function in the first LowPAN Router
(the node's default GW). 

The current draft (03, just posted) imposes that the node registration
goes though the first hop router, that either handles it (if it is ER)
or relays it (if it is only LoWPAN Router). In either case, the LoWPAN
router functionality in the first hop router maintains a binding state
upon positive Node Completion. That state binds the registered IP
address with the Link Layer Address that is received as source LLA in
the Node Registration MAC header. That state is what enables the LoWPAN
Router to forward back to the node. Draft 03 does not use NS/NA inside
the LoWPAN and thus does not require the traditional ND Neighbor cache
there. So what we could do is mandate that the LoWPAN Router uses that
same binding table to check the source of the packets that it forwards
from the attached nodes for 1) being registered properly and 2) matching
LLA.

Caveat: after the first LoWPAN router, the source IP does not match the
LLA anymore so there must be an additional mechanism in place for
trusting LoWPAN routers. 

What do you think?

 

Pascal Thubert
IP Engineering TC

[email-masked] <mailto:[email-masked]> 
Phone :+33 497 23 26 34
Mobile :+33 619 98 29 85

Cisco Systems
  Village d'Entreprises Green Side bat. T3 
  400, Avenue Roumanille
  06410 Biot - Sophia Antipolis  
  France
  www.cisco.com/global/FR/ <http://www.cisco.com/global/FR/> 

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 29 May 2009 10:56:12 -0400

Date: Fri, 29 May 2009 11:55:10 +0200
   From: "Pascal Thubert (pthubert)" <[email-masked]>

   "
   Upon receiving packets on one of its LoWPAN interfaces, the Edge
   Router checks whether it has a binding for the source address.  If
   it does, then the Edge Router can forward the packet; otherwise,
   the Edge Router MUST discard the packet.
   "

   That was fine for a backbone router in a mesh under
   situation but that seems to falls short for route over,
   because in that case the Edge Router is not necessarily
   the first hop:

The check described in the passage above seems to be
guarding against the use of a source address that is not
bound within the LoWPAN.  It doesn't appear to be concerned
with a LoWPAN node using a source address that is bound to
some other node in the same LoWPAN.  For the former,
guarding against the use of an unbound source address, I
don't think it matters whether the Edge Router is the first
hop or not.
                                  -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 29 May 2009 17:34:21 +0200

Hi Richard

Agreed but in extended the whiteboard is distributed so if your packet
get out the wrong edge router it would filter them out...

Pascal

>-----Original Message-----
>From: Richard Kelsey [mailto:[email-masked]]
>Sent: vendredi 29 mai 2009 16:56
>To: Pascal Thubert (pthubert)
>Cc: [email-masked]
>Subject: Re: [6lowpan] source address validation in ND 03
>

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 29 May 2009 12:29:26 -0400

Date: Fri, 29 May 2009 17:34:21 +0200
   From: "Pascal Thubert (pthubert)" <[email-masked]>

   >don't think it matters whether the Edge Router is the first

   Agreed but in extended the whiteboard is distributed so
   if your packet get out the wrong edge router it would
   filter them out...

Pascal,

Doesn't the Extended LoWPAN backbone take care of that?
>From 7.3:

  Addresses that are not found in the Whiteboard are queried
  over the backbone using the ND operation in place for that
  type of link, ...

Either you have a Simple LoWPAN, in which case there is only
one Edge Router, or you have an extended LoWPAN, in which
case the Edge Routers can query each other over the backbone
if they see a source address that is not in their local
whiteboard.

I think that this works for the Simple and Extended LoWPANs
as described in the draft.  It would be nice if there were a
way of having additional Edge Routers that were not on a
high-speed backbone.  An Edge Router whose other IP network
was another LoWPAN, for example.  If that were permitted, a
node would have to route packets via an edge router with
which it was registered, as you described.

                                    -Richard Kelsey
----------------
This message and the information it contains are the proprietary
and confidential property of Ember Corporation and may be privileged.
If you are not the intended recipient, please do not read, copy,
disclose or distribute its contents to any party, and notify the
sender immediately.