Pekka,
Right now the topological assumption is the norm and this is enforced with the fact that ingress filtering may or may not be on at any given point in the network. I don't believe anyone likes having to do source filtering but we need to realize that node mobility has been forced to bow to this topological correctness (see MIPv6 draft). This is the status quo from the mobility perspective.
IMO, the fact that the filtering may or may not be on at any part of an IPv4 network is understandable due to the existing deployed base of routing products. For IPv6, I am hoping we can agree on something that is more advantageous for DDoS prevention.
The ACL list filters on the first hop was making sense to me with the hope that perhaps the topological correctness could be avoided. I.e. you would get what you want. I then began to think about how the root-kits can be installed and came to the conclusion that ensuring topological correctness is the only way to quickly identify the location of an infected slave node. Once a slave is compromised, the root kit has access to all of the authentication credentials of the node; therefore, these compromised nodes would likely be able to pass any ACL checks. If node mobility relied on the ACL lists to get around topological correctness i.e. use the home address as source, the same vulnerability would exist.
Mandating source filtering for topological correctness on the first hop is a strawman proposal. This would certainly reduce the job of tracing and other tools. No one has mentioned it yet but there may be holes in this strawman as well. For instance, it is conceivable that a router itself could be compromised. A root kit on a router could easily make a packet look as if it was not a first hop packet. This, in itself, is not a reason to not mandate the source filtering on first hops, though. One could certainly argue that if this constraint were applied to IPv6, it would have more inherent protection against DDoS than IPv4. I suspect that many of these DDoS veterans may have been down this road before at some point thoughout the years and am interested to hear their views.
Although, I realize that all of the details of your proposal have not been conveyed, I believe it would simply force us to use "return to address" filtering. I hope you can see from my statement above how authentation/cryptographic DDoS prevention mechanisms can be compromised. The root-cause problem is that of insecure operating systems. Unfortunately, I'm not sure if we can do anything about this in the IETF; although, I am certainly open to informational RFCs to explain the vulnerabilities and perhaps give example code to prevent stack overflow etc..
At the same time I do not want to dissuade you from coming up with alternate solutions to DDoS or promoting the concept you have detailed below. Your suggestion seems to have some other merits than just DDoS.
We should continue to consider all possibilities from a wide range of backgrounds.
Thanks,
Glenn
-----Original Message-----
From: Pekka Nikander [mailto:[EMAIL PROTECTED]]
Sent: Sunday, March 25, 2001 7:02 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Source addresses, DDoS prevention and ingress filtering
One point that has came up several times, in various forms, in
the DDoS discussion is the idea of mandating some sort of source
address filtering, ingress filter, PRF of whatever it is called.
For example, Glenn Morrow expressed it as follows:
> I would like to again float the idea that perhaps some sort
> of filtering on source address should be mandated on the first hop.
Let me try to explain why I _think_ that source address filtering
is a bad idea, and what I _think_ that should be done instead.
This is a lenghty message since I need to go quite deep into
the basics before I get to the point; my apologies. To clarify,
I am not trying to take sides, and I don't have any personal
_opinion_ on this issue, at least not yet :-) I am sure that
some of my points have been raised several times before, but
here we go anyway. This message is divided in three parts:
A. Discussion about source address filtering
B. A comparison between source and destination addresses
C. My thoughts what should be done instead
A. Discussion about source address filtering
Now, according to my analysis, currently there are basically three
functional reasons for including the source address into IPv6 packets.
1. Source addresses are needed to be able to reply to
packets, such as unconnected UDP queries or TCP SYN packets.
2. Source addresses are needed to be able to report
back error conditions, e.g., ICMP Packet Too Big.
3. Source addresses are used for identifying upper layer
endpoints, e.g., to differentiate between TCP sockets.
It is instructive to note that in the two first cases the
source address is really needed, but in the last case it
is merely a convenient piece of information that could be
easily replaced with something else identifying the remote
endpoint (compare e.g. to HIP).
Now, mandating source address filtering attempts to add another
purpose for the source address; a purpose that I don't believe
could ever be really reliable.
4. Source addresses identify the interface through
which the packet was originated. (FALSE)
Maybe this was the original intention of the source address,
but to me it seems like the infrastructure has never really
supported this allusion. Furthermore, it is instructive to
note that even with honest nodes the source addess does not
always identify the sender. For example, some neighbour
solicitation packets carry the unspecified source address, etc.
Furthermore, even strict and mandatory ingress filtering does
not quite achieve the maxim -- if the filtering was perfect, it
would at most lead to a situation where the source address
identifies the source link of the packet, not the specific
interface at the link.
Even further, I think that there are several reasons why
even trying to achieve this illusion is a bad idea.
a) Since source address filtering would be a piece of
functionality whose malfunction does not have any immediate
local effects, I have hard time believing that we would
ever get even 90% coverage.
b) Taking the trend described at the open plenary on
Wednesday evening, i.e. internet turning more and more
into a densely connected mesh instead of being more-or-less
hierarchical tree, employing source address filtering in
any other place but the ingress router would be quite hard
operationally, and hard even at the ingress routers. We have
already seen this in the various multihoming discussions.
c) Being mandated (but not working properly), it would
encourage people to trust the source address even more
that they do today.
B. Comparison between source and destination addresses
IMHO, on instructive point of view is to compare the functions
of the source and destination addresses. Most people seem to
believe, perhaps even unconsciously, that source and destination
addresses are functionally equivalent. That is, it seems to be
common thinking that the destination address identifies the
destination interface(s) of the packet and the source address
identifies the source interface of the packet. As we know,
this is not true. Now, the question is whether we should aim
to make it true again (if it ever was) or should we abandon
that thinking altogether.
Let us consider the semantics in detail. The destination address
has semantical meaning to the routing system. We rely on the
integrity of routing information in order to get the packets to
their intended recipients. This is inherent in the nature of
the routing system. That is, the destination address or at least
the routing part of the destination address must be "correct"
for the packet ever have any changes to get delivered.
The source address does not (currently) have any such semantics.
It is just set by the sender, and used by the receiver. The only
case when an intermediate router cares about it is when it wants
to send an error report back. However, this latter practice does
not seem to be such a good idea, since the source address does not
necessarily carry information about the real sender of the packet.
In short, the practise greatly eases reflection DDoS attacks, since
you can fairly easily employ many of the routers in the infrastructure
to act as reflectors. (Just mix routing headers and hop-by-hop options.)
Furthermore, as I already pointed out, asymmetric routing, multihoming,
and mobility are all reasons why the source address should
not carry such semantics. To say this in other words, I think that
the source address should not be called "source" address but
"reply-to" address. That would be more accurate from the semantic
point of view, since it merely indicates the sender's request where
to send replies instead of identifying the real source of the address.
C. My thoughts what should be done instead
I know this is a radical idea and that it is probably too late to
propose this, but I think that we should deprecate the source
address in the IPv6 header altogether. Instead, we should use
a separate destination option, perhaps "Reply-To Address Destination
Option", whenever we assume that the recipient may not know where
to send the replies. Please note that if we use end-to-end IPsec,
we never need to use this option, and that any other TCP packets
but the first SYN packet would not need to carry it either.
Depracating the source address field from it current use would
free it for other purposes. My suggestion is that the main function
would be to use it for _recording_ the path of the packet. That is,
each router that touches the packet would (perhaps probabilistically)
somehow record its identity into the source address field. Thus,
the source address field would no longer be a source address field
but a source path field.
This would have several benefits. First, those that believe in ingress
filtering would perhaps be happy with the recorded packet path information.
Second, those not believing in ingress filtering would be happy, too,
since packets would not have to be dropped. Third, one could easily
make the reply-to address private by including the destination option
within an ESP header. Fourth, ICMP error reports generated by intermediate
routers would be sent along the source path instead of relying on the
perhaps false source address. (This might require some modifications
to the error reporting functionality, but I think that wouldn't be
that hard.)
I know that it would be virtually impossible to employ such a drastic
change to the architecture at this point. However, maybe this
suggestion could work as a source of ideas for some not-so-drastic
approach.
--Pekka
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
