On Jun 8, 2007, at 1:20 AM, Jari Arkko wrote:
Are you thinking of the router making an extra SEND operation to
verify ownership when it for the first time sees a packet? It could
send an NS and verify the resulting NA. And use this for the
forwarding decision.
This would not, however, prevent someone who can forge L2 source
addresses from claiming that an IP packet came from a host. So for
a full solution I guess you would also need to enforce L2 source
addresses, either through switch configuration or L2 security.
In a network with a switch, the switch can do a number of things that
are very helpful, including suppress non-conforming traffic. Or so
the Catalyst people tell me :-). In a wireless network, at least
according to my limited understanding of 802.11 and 802.16 radio
technologies, the access point potentially schedules use of the air
segment (that is itself a configuration thing - most have the end
systems doing that using RTS/CTS for larger datagrams) but doesn't
act as a switch unless the datagram actually has to traverse to
another LAN domain for delivery.
Yes, one could readily imagine having the receiving host or router
reply to a datagram from an unknown source by dropping the datagram
(there is a ddos vector here, and holding the datagram is a second
ddos vector) and replying with a solicit, expecting that the sender
will now reply to the solicit and repeat the original datagram.
e2e, and noting that many implementations do in fact drop a datagram
that they can't immediately forward due to the implied ddos on the
network if they don't, this means that there is some probability that
a TCP session between systems aggressively using privacy addresses
could easily only get a SYN-ACK response to the third SYN, and only
get the SYN-ACK to traverse e2e on the fourth or fifth. The algorithm
of dropping the datagram that triggers a solicit also has a ddos in
it, which those who build routers argue is a rare case and so not
statistically valuable to chase.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
