Re: Routing Header Type 0 way forward

[Iljitsch van Beijnum <iljitsch at muada.com>]

On 16-mei-2007, at 16:51, Tim Enos wrote:

> > > Should (can) something like the following be added to the draft ?:
> > > "Conformant implementations of IPv6 hosts and routers MUST not
> > > provide a way to activate RH0 processing on the system."

> > This is a very bad idea for two reasons:

> > 1. The IPv6 spec says that you MUST implement it, then having
> > something else say you MUST NOT actually use it is just bad standards
> > making

> That a spec says something which (upon further reflection of  
> working group members and others) is bad  is not seemingly a valid  
> reason to keep saying it.

> That said, the point of the two extant drafts on the RH0 subject  
> (to be combined as one) is to update the IPv6 spec.

I don't think forbidding people from implementing RH0 is warranted.  
And having two RFCs, one that says you MUST implement it and another  
that you MUST NOT, is BAD. The proper way to do this is to write a  
new IPv6 specification where RH0 is absent.

> Since the draft (if approved) would officially deprecate the use of  
> RH0, that is what compliant implementations would do.

No. Do we have an official IETF definition of "deprecate"? In my  
book, this means that a feature is considered not useful and should  
not be implemented or used. That's a different thing than saying all  
complying implementations are prohibited from implementing or using  
something.

> > 2. Maybe someone has a legitimate use for this, they should be able
> > to do so if they want

> Given the dangers associated with RH0,

There are countries in this world where (almost) any idiot can go  
into a store and buy a gun. There are dangers associated with that.  
Having RH0 enabled the way it is currently is an inconvenience; this  
feature in and of itself poses no danger.

The firewall issue is immaterial: firewalls should filter properly.  
The DNS anycast issue is immaterial: there is no danger in being able  
to send packets to an unexpected anycast instance. The only real  
issue is the DoS amplification issue.

However, it seems that few people realize that this can only happen  
in badly configured networks: in order for the amplification to  
happen, a packet must ping-pong between two nodes without source  
address validation (ingress filtering) on the intermediate links, or  
if there is a source address validation, the source address is valid  
in each direction. With proper ingress filtering, a source address  
can never be valid in both directions. So either the A and B nodes  
that the packet flows between are both in the same AS, or at least  
one of them doesn't implement proper ingress filters. In the former  
case, they should disable source routing. In the latter case, they  
should enable ingress filtering. In both cases, that's something that  
can be implemented within the AS that suffers from the abusive  
traffic, so whenever this problem occurs, it will be dealt with  
swiftly. The argument that ingress filtering isn't possible doesn't  
apply, because no equipment is both old enough that it can't perform  
simple filtering and new enough that it can run IPv6.

> > This whole issue is blown WAY out of proportion: the BSD guys should
> > not forward when forwarding is disabled, the router guys should
> > disable source routing by default (for IPv4, too, please). Problem
> > solved, bring on the next one.

> Not really solved by simply disabling.

If you disable source routing, there won't be any source routing. How  
does this leave the problem unsolved???

> Implicit in disabling something by default is:

> *that there is something sufficiently bad about it which precludes  
> its use (at least in the general case)

> *that there could be a legitimate (corner?) use case for which its  
> use is valid

> *that it therefore can be subsequently enabled

Right. So disable it by default, let people enable it if they want to.

> Respectfully, I don't think I've seen a convincing enough case for  
> RH0 use.

Yes, and as soon as you are elected the first president of the world  
you get to make decisions about what's good for the entire world's  
population.

People are old and wise to make their own decisions.

> > If, at some later date, it turns out nobody uses this feature, rip it
> > out of the next iteration of the IPv6 spec.

> It seems there is both a sufficient lack of use of this feature and  
> sufficient evidence and consensus that it ought not be used to  
> justify its (de facto) removal via approval of the draft. I would  
> think the next iteration of the IPv6 spec would reflect this.

Changing the IP specification is something we should think long and  
hard about, and we tend to do that every time we do. Taking a few  
weeks to decide to forbid people from using a feature that has been  
available for a decade is not good standards making. Brian and Bob  
made the right call, let's do what they suggest and not stumble over  
our own feet for the sake of being seen addressing "security" issues.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 at ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------