On 14-sep-2006, at 17:55, Mark Williams wrote:
In fact, if there was some way to make the application of source
address policing in some way a /sine qua non/ for any ISP with end
customer connections, then I think we would be most, if not all of
the way there.
In security, there are no prizes for "almost".
I still don't know what this effort is supposed to accomplish. Can
someone enlighten me?
Is the problem that the communication between network equipment can
be subverted with source address spoofing? As I wrote in a previous
message, source address spoofing shouldn't be an issue when the
communication is between two internal systems, and the only protocol
network elements use toward the outside is BGP which has its own
mechanisms to protect against attacks based on source address spoofing.
What source address spoofing does is allow a third party to inject
packets into the communication stream between two other systems.
However, if these two systems use reasonable security practices
(where reasonable can be as light-weight as using hard-to-guess
initial sequence numbers and ephemeral port numbers for TCP sessions
or as heavy-weight as full IPsec AH) then the only thing an attacker
can do is some form of denial of service that is hard to filter out,
either by overloading network links, buffers or processing capacity.
I don't think anyone can reasonably argue that we can get the
internet to a state where the source address is so trustworthy that
it's possible to base any kind of security on it. That leaves the DoS
issue, which was declared out of scope earlier. Ignoring that, most
denial of service can also be done WITHOUT source address spoofing,
so I don't see the point of herculian efforts to rid the internet
completely of places where a user can spoof a source address. This
just isn't going to work.
Comment on the draft - L3 source validation we OK 10 years ago -
but not
today. It has to be a L2/L3 source check today. This is why there are
more ports configured with DHCP Lease Query and IP Source Verify
(both
L2/L3 source checks) then with uRPF Strict.
Agreed. In fact in the expanded framework that is being worked on,
L2/L3 source checks in access networks is part of the picture.
Doing per-packet work to make per-session life easier is
fundamentally the wrong approach. A sad example is port 25 filtering.
99.9% of all packets flowing over the internet are other protocols
than SMTP. So installing port 25 filters to make life easier for mail
servers that insist on using a protocol that takes everything it's
told for true without any checks at all is completely backwards,
especially as the power (processing and electricity wise) for all
this filtering scales linearly or worse with the number of packets
flowing over the internet, while improving SMTP scales order O(number
of SMTP implementations).
Unfortunately, this kind of logic is found all over the place. For
instance, with TLS and IPsec moderately heavy crypto must be executed
for all packets: the ones that end up being legitimate, but also the
ones that turn out to be spoofed. A better approach than rely on
HMACs to authenticate the sender as well as the message integrity
would be for the sender and the receiver to generate a stream of hard-
to-guess bits and include part of this stream with every message so
that the first check that must be done is a simple 4 or 8 or byte
compare rather than a ~ 1400 byte MD5 or SHA-1.
I.e., we first check whether someone has a ticket before we X-ray his
baggage.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
