Hi Pekka,
It is an interesting topic you raise.
I think though that our AAA v6 draft is a big step forward and would like to
stress at a few points.
> 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.
It could though be combined with the access control that we explain in the
draft
> 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.
I agree and this is how it is more or less solved in the draft where the
authenticated address becomes a temporary link identifier with a chance to
update the ACL filter in the router based on the authentication and
authorazation phase with the home AAA server. In other words it does not
mean so much if we use the CoA or Home Adress in respective to the protocol,
but in the draft the CoA could be seen as the authenticated "link
identifier" and my belief is that it solves a lot of the issues you raise,
perhaps not all, but a lot of them.
And then you have to bear in mind that it is very easy to implement with
existing policy manager/ACL rule managers in existing routers.
>
> 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.
What do you mean here? In my view it is the easiest way to secure the access
and combine it with the AAA draft where you do you authentication and
authorazation in the AAA infrastructure, and you could reuse a lot of the
software that is already running inside the routers for handling ACL rules.
> 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.
Not if you have an option to update the ACL rules automatically that could
be done as it is described in the draft...
> c) Being mandated (but not working properly), it would
> encourage people to trust the source address even more
> that they do today.
Nothing strange. It is the same thing today in the mobile networks for
instance wher your identifier is an IMSI which could be compared to
something similar as a HA in case of mobile ipv6 with AAA.
>
> 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.
It is already split today. The HA is the identifier of the user. But your're
right, the identifier could have several semantical meanings, some might
argue that it is a "home interface" or something else. And I would like to
see the CoA as a link identifier.
> 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.)
Thats why a architechure base on filtering is so easy and in the short
perspective make sense, the access lists are enforced at the access where
the aggregated amount of traffic is not overhelming.
> 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.
To be frank, this sounds like a weaker proposal than the existing ones.
You open up the routers to allow them to write into the packet (the source
path). The problem with this approach is that it scales poorly and put more
demand on the routers not only in the access but even further up in the
aggregation, edge, core etc.
Maybe I missed your point.
Remember that I talk about packet filtering together with somthing like our
AAA v6 draft to enforce access control.
>
> 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.)
>
Best Regards
Thomas Eklund
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
