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 protected] <mailto:[email protected]>
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.
<<image002.jpg>>
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
