Sorry; that got garbled by funny characters that came from copy/paste. Here it
is again:
Problem statement: IP source addresses can be spoofed. Packet delivery is based
only on destination addresses, to the spoofed traffic arrives, and hurts
(attacks/threatens) the destination. It'd be nice to stop the spoofing, and
existing solutions aren't sufficient.
There are product solutions for ipv4, sold by Cisco and others, that work within
a single switch. The working group wants something standard.
The trouble, as I see it, is that the charter is too limited:
-----------------------------------
Specifically, the group shall define solutions such that hosts attached to the
same router cannot spoof each other's addresses. The following assumptions
apply:
- The WG considers only solutions on layer-3-aware Ethernet switches
- Two
solutions are needed, one for IPv4 and another one for IPv6
- The IPv4 solution
depends on tracking the DHCP traffic on a port
- The IPv6 solution depends on
tracking the Neighbor Discovery and DHCP traffic on a port
- All address
assignment mechanisms in IPv6 need to be supported, including stateless,
stateful, privacy, and so on
- The solutions are turned on for host ports by
configuration, and do not apply to routers
The WG recognizes anti-spoofing
deployment efforts, motivation, and best practices development in various forums
around the world (including RIPE). The WG is only chartered to deliver two
specific solution components that such efforts could employ. The bigger questions
are out of scope.
-----------------------------------
Normally, I would worry
that a charter were too broad, but this just doesn't seem to solve a problem that
I think needs a standards-track IETF solution. Any company can already sell a
switch with anti-spoofing technology in it. Another company can sell another,
with different technology. There's no issue of interoperability that I can see.
The most I can see a need for is a BCP to tell hosts what to do to avoid running
afoul of existing anti-spoofing techniques. If there's a need for a WG to do
that, OK (but I'm not convinced). But I really don't see a standards-track issue
here.
On the other hand, this isn't my area of expertise, so maybe I'm missing
something basic.
Barry
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf