Subject: New Consensus call on RH0 Deprecation

From: Bob Hinden <[email-masked]>
Date: Mon, 20 Aug 2007 13:43:19 -0700

Hi,

After the reviewing the comments received during the working group  
last call on <draft-ietf-ipv6-deprecate-rh0-01.txt> and discussing it  
with our AD, the IPv6 w.g. chairs think it would be valuable to ask  
the question again.  We want to make sure there continues to be a  
consensus for deprecating RH0 as specified in the current draft as  
opposed to restricting it's usage as was suggest in several of the  
last call comments.

We would like to get your comments on the following two choices:

1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.

2) Revising the draft to restrict the usage of RH0.  This would  
continue to require RH0 to be implemented but would restrict the  
functionality of RH0.  For example, require nodes to have support for  
RH0 turned off by default, limit the number of RH0 headers in a  
packet to one, limit the number of addresses in the RH0 to a smaller  
number (e.g., 6), and and a requirement that addresses can only be in  
the header once.

Please send your answer this question (including why) to the list or  
to the chairs directly.  We will review the responses and report the  
results to the w.g. early next week.  We are not trying to start a  
debate, but want to get a new measure of the consensus.

We note that if there continues to be a consensus for 1), then we  
will forward the draft to the ADs for proposed standard.

Thanks,
Bob Hinden & Brian Haberman
IPv6 w.g. Chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 20 Aug 2007 16:51:22 -0400

Dear colleagues,

> 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.

I support this option, because it seems to me that the existing draft
makes the correct point: another rh[n] could be introduced to add the
desired features without exposing the same vulnerability.  Given that
the deployment so far is not extensive (compared to other things on
the Internet), it seems like this is the safest thing to do.  I have
read the alternative arguments; some of them seem to me to be
reasonably good second choices, and if we had evidence of much wider
use of RH0 today, I would probably be more persuaded by those
arguments.

Best regards,

Andrew

----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

---

From: Ryan McBride <[email-masked]>
Date: Mon, 20 Aug 2007 22:48:29 +0000

> 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.

I don't agree with all the details of this draft (particularly the
language around firewall policy), but I believe deprecation to be the
correct approach. Creating a situation where RH0 is /sometimes/ OK,
without any way of knowing if the endpoints can handle it correctly,
creates serious problems for network operators who value security over
unrestricted end-to-end connectivity.

> 2) Revising the draft to restrict the usage of RH0.  This would continue to 
> require RH0 to be implemented but would restrict the functionality of RH0.  
> For example, require nodes to have support for RH0 turned off by default, 
> limit the number of RH0 headers in a packet to one, limit the number of 
> addresses in the RH0 to a smaller number (e.g., 6), and and a requirement 
> that addresses can only be in the header once.

My understanding is that besides the requirement to disable RH0 by
default these controls would be fairly difficult to implement
efficiently in hardware. Such a draft would be either be unimplemented
or ammount to mandating another DDoS mechanism on the slow path of core
routers.

-Ryan

---

From: Joe Abley <[email-masked]>
Date: Mon, 20 Aug 2007 18:55:16 -0400

> 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate- 

I support this option since:

1. I think it is the clearest solution to the problem (as in, easiest  
to understand). I believe clarity is important here, since ambiguity  
seems like a path to "let's block all routing headers, just to be on  
the safe side".

2. It facilitates identification of "dangerous" source-routing in a  
way that is already available on several platforms (checking the RH  
type) without requiring devices to distinguish between old and new  
semantics (as would be needed in the case of a shared codepoint  
between the original and new specification).

3. Architecturally, choosing a new codepoint for functionality which  
is different, even if it is similar, seems like the right thing.

4. It is congruent with the approach several significant  
implementations have taken (e.g. Linux, *BSD, Mac OS X).

5. Nobody has come forward with an indication that functionality  
requiring RH0 in its current form is widely deployed or required. It  
seems at least plausible that we might expect to have heard of such a  
use case given the publicity surrounding the CanSecWest presentation,  
regardless of whether you choose to classify that publicity as  
"hysteria" or "journalism" :-).

6. It seems likely that some IPv6 operators have taken the precaution  
of dropping datagrams carrying RH0, and hence the zero type might be  
considered effectively poisoned for use on the public Internet. Re- 
use of type zero would hence only be of reliable use within  
controlled networks; to be of general use, a benign source routing  
option would need a new codepoint.

Joe

---

From: james woodyatt <[email-masked]>
Date: Mon, 20 Aug 2007 17:28:16 -0700

> I support this option since:

I do too, and I'd like to add to what Joe has written.

> 6. It seems likely that some IPv6 operators have taken the  
> precaution of dropping datagrams carrying RH0, and hence the zero  
> type might be considered effectively poisoned for use on the public  
> Internet. Re-use of type zero would hence only be of reliable use  
> within controlled networks; to be of general use, a benign source  
> routing option would need a new codepoint.

The way we responded to the RH0 issue in the latest release of  
firmware for AirPort Extreme 802.11n base station products is to not  
forward any datagrams carrying RH0 upon receiving them on any  
interface.  I'm pretty sure we send ICMP errors in response to them,  
but that could change in the future.  There is no human interface for  
changing this behavior in the IPv6 router function.  The filter is  
always on if IPv6 routing is on.

>> functionality of RH0. [...]

I predict a draft that describes a less restrictive policy for  
handling RH0 datagrams will be ignored by everyone who has already  
shipped more restrictive products.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "George V. Neville-Neil" <[email-masked]>
Date: Tue, 21 Aug 2007 10:28:04 +0900

At Mon, 20 Aug 2007 13:43:19 -0700,
> 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.

I support option 1.

Best,
George

---

From: "Vishwas Manral" <[email-masked]>
Date: Tue, 21 Aug 2007 07:49:10 +0530

Hi Bob,

> 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.
I support this option.

I think having a new header i.e. RH4, should be added with the below
mentioned functionality. I have already got a draft for the same. I
will post it today.

Thanks,
Vishwas

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 21 Aug 2007 14:03:38 +0900

> 2) Revising the draft to restrict the usage of RH0.  This would  

If I were to choose one I support choice #1, but I can live with
choice #2 (but in that case just turning it off by default seems
sufficient to me).  The most important point for me is to make the
consensus as quick as possible rather than sticking to a super-perfect
solution and wasting more time.  So, if there are still a
non-negligible number of people who object to the deprecation while
the vast majority *can live with* off-by-default, I think we should go
for it.

Some detailed comments:

I prefer choice #1 because it looks cleaner resolution.  Also, since
(as far as I know) not so many people are heavily relying on RH0 right
now, I believe they can generally wait for new types of RH for their
specific purposes.

But at the same time, I guess getting new RHx deployed will take
pretty long time (e.g., one-year) realistically, especially due to the
infamous time-consuming standardization process at the IETF (I'm
afraid we're not even sure where to discuss the spec - apparently 6MAN
is not the place).  So it's understandable to me for those who prefer
choice #2 to oppose to the idea of hasty deprecation.  Thus I can also
live with choice #2.

I've heard an argument that off-by-default is not sufficient, but I
personally do not necessarily agree with that.  I stated my personal
opinion on this somewhere else before:
http://mail-index.netbsd.org/tech-net/2007/05/20/0003.html
The argument that if the node is controlled by a remote attacker the
feature may be re-enabled is not convincing to me either because in
that case the attacker can do any other evil things including even
replacing the kernel implementation or running a user-space bouncer
application that has the same effect of RH0.  I'm not arguing I prefer
choice #2 by saying this, but choice #2 certainly works for me as a
compromise if that makes a quicker decision.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 21 Aug 2007 14:09:37 +0900 (JST)

> sufficient to me).  The most important point for me is to make the

	for me, the point is to ship the document as an RFC sooner, the better.

	there are giant companies who are waiting for RFC to be published.
	they are holding their security updates until RFC gets published.

itojun

---

From: Ignatios Souvatzis <[email-masked]>
Date: Tue, 21 Aug 2007 08:46:11 +0200

> 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.

Fine with me.

	-is

---

From: "Bonness, Olaf" <[email-masked]>
Date: Tue, 21 Aug 2007 09:52:27 +0200

> 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.

I vote for this option. It's a clean solution and leaves as well place for a future (re-)definition of additional RH functionalities if needed.

My 2 cents
	Olaf

---

From: David Malone <[email-masked]>
Date: Tue, 21 Aug 2007 11:21:56 +0100

> 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.

I would have originally supported option (2), because it would have
allowed RH0 to be used in a relatively harmless way. However, I now
believe (1) is the practical option, because as Joe says, we can
consider RH0 as "poisioned".

	David.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 21 Aug 2007 14:54:14 +0300

A message from your AD...

First, I would like to encourage the group to make a timely
decision on this issue, fix the specifications, and move on.
Not because this particular issue is somehow bigger or
more crucial than others (it isn't). But because we need
to deal with fixing bugs and security vulnerabilities
from our specifications in a timely manner so that corrections
actually end up in RFCs rather than staying in the
folklore of the Internet community for years :-)

And I would like to move on also because I know
there are other issues and bugs we need to deal
with in this WG and elsewhere. We will treat them
with the same careful, analytic approach to figure
out if there really is an issue and what the best way
to deal with it is. We are not affected by bloated
claims of how bad an issue is, but neither are we
neglecting our duty to correct an error if we see
one.

Let me also remind people that we are here to
make standards for the Internet, things that go
into all hosts and routers. Consenting parties
can go beyond these standards or choose to
implement additional standardized features. But
we need to be careful about how much we require
from a general Internet node, and be clear about
how widely a feature (or a fixed feature in this case)
is expected to be used when we make a decision
about it.

Finally, as someone who has personally allocated
a new RH type number (2) for his spec, I can
say that the experience was generally pleasant
and can be recommended for others -- nothing to be
afraid of if there is a need for it.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Aug 2007 12:58:38 +0200

> 1) Deprecate RH0 as specified in <draft-ietf-ipv6-deprecate-rh0-01.txt>.

This is my preference. It's the only way to be sure the problem
is definitely fixed.

> 
> 2) Revising the draft to restrict the usage of RH0.  This would continue 
> to require RH0 to be implemented but would restrict the functionality of 
> RH0.  For example, require nodes to have support for RH0 turned off by 
> default, limit the number of RH0 headers in a packet to one, limit the 
> number of addresses in the RH0 to a smaller number (e.g., 6), and and a 
> requirement that addresses can only be in the header once.

I would prefer this to be done using a new RH number. Redefining an
existing header in this way will cause operational confusion.

    Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 22 Aug 2007 11:00:44 -0400

Hi Bob,
   I would go for Option 1(deprecate), though I am not sure it is 
reasonable to assume people will "unimplement" the code for RH0 for 
already deployed implementations. Option 2 is also acceptable to me.

Thanks
Suresh

Bob Hinden wrote:
> Hi,
> 
> After the reviewing the comments received during the working group last 
> call on <draft-ietf-ipv6-deprecate-rh0-01.txt> and discussing it with 
> our AD, the IPv6 w.g. chairs think it would be valuable to ask the 
> question again.  We want to make sure there continues to be a consensus 
> for deprecating RH0 as specified in the current draft as opposed to 
> restricting it's usage as was suggest in several of the last call comments.
> 
> Please send your answer this question (including why) to the list or to 
> the chairs directly.  We will review the responses and report the 
> We note that if there continues to be a consensus for 1), then we will 
> forward the draft to the ADs for proposed standard.
> 
> Thanks,

---

From: Jason Schiller <[email-masked]>
Date: Mon, 27 Aug 2007 11:05:04 -0400 (EDT)

> number (e.g., 6), and and a requirement that addresses can only be in  
I am in favor of option 2.

With regard to RH0 and source routing in general I do not believe the best
approach is to deprecate this functionality.  

Feature parity between IPv4 and IPv6 is important to ease transition and
transition concerns.  I wonder how much support there would be to
deprecate IPv4 source routing.  

Also, if source routing in some sort of new and limited form turns out to
be useful, RHx could be specified and implemented in new extension header,
but the same is not true for IPv4.

I do concede on the point that almost no one uses it.  As a transit
provider, we have disabled IPv4 source routing.  We have done this to
protect our network.  We don't want our routers to do expensive software
based forwarding decisions.  We don't want to allow customers dictating
traffic engineering decisions within our network.   Unfortunately, our
only recourse is to turn off source routing and drop all packets that have
any source routing options.

It would be better if we had the capabilities to ignore source routing
options.  This way each network could make its own security decisions
instead of the transit ISPs acting like a firewall for the Internet and
deciding what traffic is good for the Internet.

How would ignoring source routing work?
------------------------------------------------------
Routers could be configured with one of three options:
1. drop all packets with source routing options. Current 
   "no-source-route" or "no ip source-route"
2. ignore source routing.  Use standard forwarding if the destination is
   not the local router.  If the destination is the local router discard
   the packet.
3. honor source routing.

This would allow for a given network to protect itself and not be used for
source routing, but would not prevent network beyond your network from
honoring source routing.  For example take customers A, B and C who are
connected to ISP1.  ISP1 does not want their routers to be used as a
source routed node, so they configure ignore-source-route. 

Customer A and customer B as two consenting adults may decide to support
source routing.  This could allow customer A to source a packet that will
be source routed inside customer B's network.  Since the packet does not
have a destination of a router in ISP1's network it will just transit ISP1
like any normal traffic.  When it reaches customer B, since they support
source routing, the traffic will be source routed.

Customer C may configure no-source routing.  Customer A may send packets
that are to be source routed inside customer C's network.  In this case
the ISP1 will transit the traffic to customer C's network where it will
get dropped.

Customer A may try to source route a packet in the middle of ISP1's
network.  In this case ISP1 will carry the traffic to the middle of the
network, where the router that is the next hop destination will discard
the traffic.

__Jason

==========================================================================
Jason Schiller                                               (703)886.6648
Senior Internet Network Engineer                         fax:(703)886.0512
Public IP Global Network Engineering                       [email-masked]
UUNET / Verizon                         [email-masked]

The good news about having an email address that is twice as long is that
it increases traffic on the Internet.

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 28 Aug 2007 00:14:23 +0900 (JST)

> but the same is not true for IPv4.

	see the text carefully.  (1) says "deprecate *RH0*", (2) says
	"restrict the usage of *RH0*".  it is not about RHx.  will your
	choice change because of this?

	and for what it's worth, IPv4 options entirely deprecated in reality.
	packets with any IPv4 options could not go through JP-US link at least
	since 1992 or so.  therefore, IPv4 equivalent of RH0 has been dead
	for 15 years.

	i'm, of course, in favor of (1), and the document has to be shipped
	as soon as possible.  there are huge vendors which holding up the
	release of security advisory until RFC gets published!

itojun

---

From: [email-masked]
Date: Mon, 27 Aug 2007 13:08:53 -0400 (EDT)

> use of RH0 today, I would probably be more persuaded by those

Ditto.

Brian Dickson
Afilias

---

From: Jason Schiller <[email-masked]>
Date: Mon, 27 Aug 2007 14:08:56 -0400 (EDT)

> 	choice change because of this?

I am quite aware that choice 1 is Deprecate RH0 and choice 2 is restrict
usage of RH0, and neither relates to RHx.

I think maybe you are missing my point.  It relates to a more general
discussion of source routing and feature parity in IPv4 and IPv6.  If you
are going to deprecate IPv6 source routing, then you should also deprecate
IPv4 source routing.  If you think that maybe IPv6 source routing is
useful, especially in a more limited fashion, then that can easily be
defined in another IPv6 RHx extension header.  But the problem is much
more complicated if you want feature parity with IPv4 as you would need to
modify the IPv4 header.

For this reason I would prefer greater control over how to deal with
source routed packets (IPv4 and IPv6).  I am not opposed to changing the
defaults (in both IPv4 and IPv6) to prevent source routing.  I think it
would be good to require all vendors to support a single config bit to
prevent source routing.  

But if we are going to re-think source routing, I think there are better
options then either supporting source routing, or discarding all packets
with a source routing option.

> 	since 1992 or so.  therefore, IPv4 equivalent of RH0 has been dead

Again, some people seem to think source routing is useful, other are
afraid of the security risks.  Each network operator will act in their own
best interest.  Currently the only options are either allow your devices
to perform source routing, or drop all packets that are transiting the
network with source routing options.

There is middle ground here.  Allow routers to be configured such that
they can ignore source routed packets that are not destined to the local
router.  This will allow routers to forward source routed packets in the
normal way without an impact on software based forwarding.  This will
allow an operator to secure their own network and not allow their network
to be used for source routing, while not preventing networks that are
reached through them to use source routing if they so desire.  This way
everyone can decide for themselves if they want to support source routing
unlike currently where all of the transit providers have made the decesion
on behalf of their customers.
 
> 	release of security advisory until RFC gets published!

I am still in favor of choice 2.  

I would be curious how people feel about these choices if they also apply
to (as they should) IPv4 source routing.

__Jason

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 28 Aug 2007 03:23:19 +0900

>discussion of source routing and feature parity in IPv4 and IPv6.  If you
(snip)

	ok, i assume you have not seen this.  http://www.natisbad.org/.

	the key topic being discussed here with the draft is URGENT need to
	publish the deprecation/restriction of RH0.

	please refrain from generalizing the problem, until RH0 RFC goes
	out of the door.  we can handle your generic opinions about the
	source routing in general some other time.

	again, it is about rather serious security problem, which risked
	the DNS root name servers.  it's quite serious and really urgent.
	the RFC publication should have finished way earlier.

itojun

---

From: james woodyatt <[email-masked]>
Date: Mon, 27 Aug 2007 11:26:18 -0700

On Aug 27, 2007, at 11:08, Jason Schiller wrote:
>
> I would be curious how people feel about these choices if they also  
> apply to (as they should) IPv4 source routing.

I was unaware until just now that IPv4 source routing had *not* been  
deprecated by IETF already.  I must have been misinformed about  
that.  It's certainly not viewed with any favor among the circles  
I've been in most recently.

---

From: James Carlson <[email-masked]>
Date: Mon, 27 Aug 2007 14:35:30 -0400

> 	the RFC publication should have finished way earlier.

Of course security problems are important.  However, fixing them in
the field is _never_ dependent on publishing an RFC, because the RFCs
themselves are not executable.

If there really are vendors that are failing to fix security problems
because they want to see an RFC published first, then I'd suggest
either taking that up directly with those vendors or simply choosing
not to buy their products.

I think that dismissing concerns about coherence and direction in the
RFCs because of a desire to rush publication is short-sighted at best.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: [email-masked] (Arnaud Ebalard)
Date: Mon, 27 Aug 2007 21:22:29 +0200

Hi Jason, Hi *,

>> number (e.g., 6), and and a requirement that addresses can only be in  

I am in favor of option 1 for all the reasons provided by Joe in a
previous post. 

> options.  

And even better if we had the insurance that all devices do not process
RH0 at all. 

> deciding what traffic is good for the Internet.

IPv6 without RH0 is good for the Internet (ISP, networks and users). It
has no specific additional prerequisites for users and operators as it
follows their expectations, i.e. it flows End-to-End.

Furthermore, its associated operational cost is null and it does not
remove any _useful_ functionality (as already discussed on the list).

Trying to secure RH0 use in the Internet has a cost (implementation,
education, configuration) and an already proven null ROI (even negative
given the time lost in past decade to specify it, implement it and ...
deactivate it). 

Having a rock solid infrastructure for IP communications (simple,
reliable and efficient) is certainly preferable to a pick-up-sticks
structure that will collapse if one of the hypothesis on which it is
built does not hold anymore.

Regards,

a+

---

From: [email-masked]
Date: Mon, 27 Aug 2007 15:27:16 -0400 (EDT)

> themselves are not executable.

While this is technically true, it is a red herring.

The real question is, are there situations where revising an RFC is
necessary, where the result of the RFC *doesn't* require that a new
functionality or change in functionality be built?

The answer here is yes, and is directly on-topic.

The reason the RFC needs to be changed, is that the *default* behaviour,
not the supported kinds of behaviour, is being changed.

The RFCs specify all kinds of things, with language like MUST and MAY.

And the impediment to fixing things in the field, is that vendors need
to maintain interopability. This requires RFCs. Vendors who ignore RFCs,
cause problem for everyone. So, even if some vendors are willing to make
the change, most would prefer, and some require, that the RFC be changed
*first*, so that they do the change to maintain RFC compliance, as compared
to making a change which, while the right thing, violates the RFCs.

> not to buy their products.

The risk of RH0 requires that *all* vendors fix the issue, since it has
bearing on even those parties that have to some degree disabled processing
RH0 packets directed at their gear.

> RFCs because of a desire to rush publication is short-sighted at best.

I agree. I also believe that well-thought out and coherent RFC proposals,
whose timely publication are needed to address actual concerns, should
be given appropriately timely consideration. I also believe that only
the technical content of the RFC should really be what we're talking about,
in any RFC discussion, rather than delaying action on it because of
abstract meta-issues which do not bear on the RFC.

(There can well be situations where the meta-issues *do* bear on the RFC
and/or other RFCs, especially when convicted monopolists are attempting
to modify RFCs to their own ends. But when no such issue exists, we should
avoid dragging those kinds of questions into the discussion.)

Do you agree that the proposal, as written, has very narrow scope?
Do you agree that adoption of the RFC may require vendors to change code
to support the RFC?
And do you agree that if code is changed, to be universally supporting
the RFC, and deployed everywhere, that the RH0 security issue goes away?

If so, I would suggest the appropriate response is to express any concerns
you have, but to also support the proposal.

And if you happen to represent a vendor of IPv6 code, that you either do
the code fix unilaterally, or support the proposal, since the general
consensus is that this needs to be fixed. Or even abstain, if you feel
conflicted. But I don't think opposing this proposal, on any of the grounds
you have suggested, is entirely appropriate -- IMHO.

Brian Dickson
Afilias

---

From: Jari Arkko <[email-masked]>
Date: Mon, 27 Aug 2007 22:42:15 +0300

Hi Jason,

> It relates to a more general
> IPv4 source routing.

For the record, earlier review of the IPv4 source routing RFCs
convinced me at least that we may need to make some changes
in the IPv4 side as well.

I have been holding off to start the work while the IPv6 side
work is still in progress, mainly because its easier to deal
with one issue at a time, and because largely the same
people would be involved. But I do think we need to look at
the IPv4 side as well.

The functions are somewhat different, as is deployment
situation -- so I'm not sure complete "feature parity" will
result. But at least we should look at this with the same
technical analysis as we have done in the RH0 case. What
are the issues? What is the implementation and operational
reality vs. what the RFCs are saying? Do the RFCs (such
as 1812) need updating?

Jari

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 27 Aug 2007 15:53:22 -0400

Hi Jason,

> to (as they should) IPv4 source routing.

I think the problems, though overlapping, are completely different in 
magnitude. The problem with IPv4 source routing is not AS SEVERE as the 
problem with RH0. The main issue I have with RH0 is the NUMBER OF 
ADDRESSES that can occur in the header, rather than the concept itself. 
I don't think there is a valid use case for this number of addresses as 
allowed for in RH0.

Cheers
Suresh

---

From: James Carlson <[email-masked]>
Date: Mon, 27 Aug 2007 15:48:31 -0400

> While this is technically true, it is a red herring.

I don't think it's a red herring at all.  The previous poster was
conflating RFC publication with actual code change.  The two are
distinct.

> to making a change which, while the right thing, violates the RFCs.

I think a vendor that prides itself on specmanship rather than
security and demonstrated interoperability is probably a lost cause
anyway.

In this case, what you're saying is effectively (also?) a red
herring.  It's not the case that vendors who shut down RH0 long ago
were somehow causing "interoperability" problems, or that having the
RFC published somehow makes any such problems go away.

It may well be the case that (with _other_ changes), a flag day is
necessary.  This clearly isn't one of those cases.

> RH0 packets directed at their gear.

Thinking that publishing the RFC will actually cause them to change
seems like a different sort of risk to me.

> Do you agree that the proposal, as written, has very narrow scope?

Yes.

> Do you agree that adoption of the RFC may require vendors to change code

No.  The IETF has no police and can't really force anyone to do
anything.

> the RFC, and deployed everywhere, that the RH0 security issue goes away?

Yes.

> you have, but to also support the proposal.

I wasn't expressing any lack of support for the proposal.  I was
expressing support for Jason Schiller's on-topic discussion of the
options.

I don't think that Jun-ichiro itojun Hagino's response to him was
helpful.  It's alarmist and incorrect to say that delaying RFC
publication in order to get the wording right means that people can't
deploy _today_ based on the draft.

Don't most people intentionally deploy implementations based on drafts
anyway?

---

From: Jason Schiller <[email-masked]>
Date: Mon, 27 Aug 2007 16:20:05 -0400 (EDT)

> 	the RFC publication should have finished way earlier.

Itojun-san,

Thank you for the URL http://www.natisbad.org/.  

I have been closely following the RH0 discussion as it relates to ISP
network security and the implications on the specific routing gear in my
network.  I have closely examined the security bulletins from my vendors,
and have specified the required testing of their current functionality and
possible work around configurations.    

I am also quite aware of the security implications including:

1. The possibility of end-sites making traffic engineering decisions about
how traffic is forwarded across my network.

2. The possibility of a DoS attack on a link by looping traffic between a
pair of routers or hosts

3. The possibility of circumventing firewall filters by specifying a good
destination, and then source routing the packet behind the firewall to a
filtered destination.

I have only loosely followed the discussion with regard to Unix / Linux
implementation of RH0, and believe the problem to be the same as for some
router vendors who have not provided a configuration statement to discard
source routed IPv6 packets.  I do appreciate the additional links
discussing the RH0 problem wrt particular host operating systems.

I do appreciate the importance of this issue.

We can all agree that at the very least all vendors should offer the
ability to easily discard source routed packets.

I am agreeable to making that the default behavior, although I suspect
there will be some push back as people tend to be uncomfortable whenever
defaults change.  Generally people get upset when they depend on a
default, and then the upgrade their version of Cisco IOS and the default
changes and something breaks.

I understand that this work is holding up getting vendors to modify their
code.

I personally would like to see my vendors offer BOTH the ability to
discard source routed packets, as well as the ability to ignore source
routed packets.  However, if IPv6 source routing is deprecated, then it is
unlikely that they will provide this functionality as it will violate an
RFC.  This is why I prefer option 2.

With regard to generalization I think it is important that we consider
feature parity with IPv4 and IPv6 and understand the implications of
deprecating IPv6 RH0 on IPv4 source routing.

Thanks,

__Jason

---

From: Scott Leibrand <[email-masked]>
Date: Mon, 27 Aug 2007 13:32:50 -0700

Jason,

I haven't been following the RH0 deprecation discussion quite as closely 
as you have, but it seems to me that your concerns would best be 
addressed by creation of a new RH option to support a safer form of 
source routing.  My understanding is that RH0 is a lot like directed 
broadcast (smurf amp), in that if you can find two networks that support 
RH0, and ISP(s) in the middle that allow it, that opens up a DoS 
vector.  As a result, I think everyone needs to discard RH0 packets, and 
that the ability to ignore (pass-through) source-routed packets would 
best be implemented with a new RH option with tighter security.

I guess that makes me #17 in favor of option #1.

-Scott

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 27 Aug 2007 17:02:33 -0400

On Mon, Aug 27, 2007 at 03:53:22PM -0400, Suresh Krishnan wrote:

> problem with RH0. 

Also (and this seems to have been overlooked up-thread), we're in
relatively early days with IPv6, so the installed base we have to go
around and tell "RH0 bad" is quite a bit smaller than whatever people
might be doing with IPv4.  I'm aware that there are significant v6
deployments, but it's still tractable.  Since someone has identified
the problem with RH0, the time to do something about it is now,
before many more people build things that might depend on it.

A

-- 
Andrew Sullivan  | [email-masked]
The very definition of "news" is "something that hardly ever happens."	
		--Bruce Schneier

---

From: Jason Schiller <[email-masked]>
Date: Mon, 27 Aug 2007 17:43:22 -0400 (EDT)

> before many more people build things that might depend on it.

It is one thing to say RH0 (and by extension IPv4 source routing) is bad
for my network, and therefore my network will not support source routing.

It is quite another thing to say RH0 (and by extension IPv4 source
routing) is bad for my network, and therefore no one will be able to use
source routing.

What I am advocating is that each network be able to make their own
decisions about supporting source routing and not be at the mercy of
everyone that is upstream from them.

no-ip-source-routing  = the option to turn off source routing for my
                        network and everyone down stream.

ignore-source-routing = the option to turn off source routing in my
                        network.

Deprecating RH0       = no IPv6 source routing.  And will likely lead to
                        deprecating  IPv4 source routing.

In the short term, lets make sure all vendors support
no-ip-source-routing, and in the long term add the flexibility to ignore
source routing.

And lets discuss if no-ip-source-routing should be the default action or
not. (personally I don't care either way as long as IPv4 and IPv6 are
consistent, and there is a fair amount of notification if current defaults
change).

I'm not suggesting that we hold up the draft until the
"ignore-source-routing" spec can be written.  I do think if source routing
(IPv4 and IPv6) is depricated, then we will never get this flexibility.

__Jason

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 28 Aug 2007 17:00:07 +0900 (JST)

> relatively early days with IPv6, so the installed base we have to go

	"small" includes 22 million copies of MacOS X.

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 28 Aug 2007 17:07:52 +0900 (JST)

> Don't most people intentionally deploy implementations based on drafts

	some of the major IPv6 implementation certification firm, and some
	vendros of IPv6 implementation with rather serious number of
	actual shipping/deployment, do implement RH0, and do require RH0
	to get certification, because of what is documented on the RFC.

	so the spirit of "request for comment" is not widely understood....

itojun

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Tue, 28 Aug 2007 17:13:54 +0900 (JST)

> I've been in most recently.

	packets with IPv4 options wouldn't go far because too many
	routers do not pass it, or do not support it.

itojun

---

From: David Malone <[email-masked]>
Date: Tue, 28 Aug 2007 10:04:14 +0100

> magnitude. The problem with IPv4 source routing is not AS SEVERE as the 

Actually - I've a feeling that at the time the problems with IPv4
source routing were discussed, they would have been considered more
severe. They allowed remote user (or maybe even root) level access
to many systems. At the time DoSes weren't considered so serious.
Today, a DoS, even with a magnification factor of 80 or so, is
probably less severe in my mind. YMMV...

	David.

---

From: "Christopher Morrow" <[email-masked]>
Date: Tue, 28 Aug 2007 23:45:15 -0400

> > magnitude. The problem with IPv4 source routing is not AS SEVERE as the

The 'problem' with source-routing is that people forgot that it
exists, plain and simple. Then someone stood up and said, look! with
source-routing I can ... source-route packets! and I can do 'bad
things'.

Then people got all flakey and decided we better just turn that off
and remove it from the protocol :( people haven't removed ICMP from
the earth and it's been responsible for more 'security incidents' over
time than source-routing. The same goes for http for that matter.

> to many systems. At the time DoSes weren't considered so serious.

Yup, and someone/no-one noted this as a real concern with ipv6 RH0,
everyone focused on the least interesting problem and decided to
shutdown RHO and excise it from the protocol... a blatant knee jerk
reaction. It's interesting to me that this blatant knee jerk reaction
is getting a base protocol level change, yet locator/id split isn't.
It's interesting that folks feel in this instance ipv6 is 'less used
and less critical' and thus able to be changed where in the locator/id
split discussion that argument was not acceptable.

'hypocrisy' I think is the word I'm looking for?

> probably less severe in my mind. YMMV...

and 80x magnification is a problem... but in this case (and in many
other cases of same) there are simple solutions that could/should be
used. Solutions which don't require base protocol changes.

-Chris

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 29 Aug 2007 09:55:56 +0200

Hi,

> used. Solutions which don't require base protocol changes.

Can you describe those _simple_ solutions and compare them with the
deprecation? ;-)

IMHO, the real problem is that RH0 should not have been in the IPv6
specifications (1883 _and_ 2460) and the associated time/space could
have been used, as you wrote, for something more useful. 

locator/id split is actually one of such things, but having it directly
in IP has pros and cons. Keeping IPv6 simple and efficient allows
building on top of it (like MIPv6 does) with some insurance on resulting
stability.

Regards,

a+

---

From: "Christopher Morrow" <[email-masked]>
Date: Wed, 29 Aug 2007 10:47:00 -0400

> Can you describe those _simple_ solutions and compare them with the

Sure, if you see a problem related to the ping/pong between 2 devices
simply filter that traffic. The sky is not, in point of fact, falling.
There is no difference between this sort of security problem and
smurf-attacks or syn-floods. (speaking as someone that's had to
protect thousands of customers and a sort-of-large network for 8+
years from these sorts of issues).

> have been used, as you wrote, for something more useful.

Sure, the original idea was probably (I've not read the history) to
have feature parity as much as reasonably possible. I suspect that
when 1883 and 2460 were written source-routing in ipv4 was still
somewhat useful. Today, for a variety of reasons, it's become mostly
not-usable except in specific applications.

> building on top of it (like MIPv6 does) with some insurance on resulting

Certainly, doing so scalably (like making all of ipv6 MIPv6 instead of
a special class of MIPv6 capable endopints) would have been a much
better long term solution :( Essentially, as a number of presentations
I've given or [email-masked] has given, the world IPv6 was designed for
didn't appear. The assumptions inherent in the design (the largest
mis-assumption being a small number of large providers with aggregate
routing and addressing) have driven us to a wierd place...

thanks,
Chris

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 29 Aug 2007 18:40:09 +0200

> functionality of RH0.  For example, require nodes to have support  
> for RH0 turned off by default, limit the number of RH0 headers in a  
> packet to one, limit the number of addresses in the RH0 to a  
> smaller number (e.g., 6), and and a requirement that addresses can  
> only be in the header once.

My objections to the draft:

- I do not consider this a security issue as such
- I don't consider this text to be proper use of the word  
"deprecate", "remove" would be more appropriate
- not specified that processing the header in a system functioning as  
a host is erroneous
- overly aggressive stance on future use of the mechanism

So if the above are my only two choices, I'm coming down in favor of 2.

However, what I'd really like to see is a clear statement that hosts  
MUST NOT send out packets not generated locally, for reasons of the  
RH0 header or otherwise, and "optional to implement" and "off by  
default" language. That leaves current and future implementations the  
freedom to implement and administrators to enable the mechanism if  
and when desired.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Aug 2007 14:48:03 +0300

Chris,

> is getting a base protocol level change

The RH0 case is not one of the big issues facing the Internet.
As bugs and changes go, its a very small one.

This does not imply that we can forget it and do nothing. The
IETF is responsible for its specifications much the same way
as vendors are responsible for their products. When there's
a bug or a security vulnerability in our specifications, it is
our duty to take notice and take appropriate. Perhaps we
can debate what that action should be, but it most certainly
should include documentation of the issue, and in some cases
modification of the spec in question.

I realize that in many cases what has happened is that the
RFC stays unchanged, and a body of knowledge is developed
outside the RFCs (code in common implementations; papers
in conferences; discussions on lists; word of mouth) about
what should be done. I do not think this mode of operation
is appropriate, or at least not appropriate in all cases. We
owe it to the consumers of our specifications -- implementors,
for instance -- that we keep them up to date and that they
contain all the information required to implement and use
the feature in question.

I respect your opinion that this is a knee jerk reaction,
but disagree with that characterization, and so did most
of the people who were involved in the discussion. On
a personal note, I find it amusing that a couple of months
ago we had to calm people down and assure that this
is just another bug and we'd deal with it the way we deal
any other issues. Now we're using same words to argue
that we're not giving in to hysteria...

> yet locator/id split isn't.

I share your frustration, there is nothing that I would like
better than getting an identifier-locator separation in
our stack. (Or having one there already, but then you have
to lend your time machine to us.)

However, the way to get there is to not block bug fixes
or other ongoing work. What we need instead is (a) work
towards identifier-locator solutions that are far enough
in the design that we can actually adopt them and (b) people
who start to use these things in their networks. As you
know, there is ongoing work in the IETF, e.g., in HIP WG/RG
and the RRG. The former has more issues in class b, the
latter has more issues in category a. I'm very hopeful that
we'll get a positive end result, but we are not there yet.

The criteria for adopting either a bug fix or a new feature
is the same that it has always been:

- We have a solution ready for adoption (no missing parts,
  does not cause major security issues)
- We understand how it can be deployed and how it affects
  backwards compatibility.
- We have agreement on adopting it.

So - I would suggest that we get to work on this, too.

Jari