On 7/5/07, Vishwas Manral <[EMAIL PROTECTED]> wrote:
Hi Chris,

I think the general view was that RH0, can be deprecated and a new
more secure Routing Header can be used to get the functionality for
required.

So, sure... my fear is that lots of baked code/hardware today is going
to do 'funny things' ... and isn't going to get replaced any time
soon. I admit that I'm not sure that routing gear could be easily
'modified' to  ignore RH0 either, so maybe my fear is moot.


I have put a draft for the checks required, in any such header. I
intend to modify the draft to take care of introducing the new Routing
Header. It would be great to hear of use cases from the operators
where the functionality is required.


unfortunately I can only come up with a sample cheesey example: (which
depends on the applications doing RH0 tagging)

an enterprise has a set of links between remote sites ( one expensive
and low-latency/low-jitter/low-loss, one the opposite ) Perhaps it
makes sense for them to push their voip across the 'better' link and
everything else on the 'bad' link. They could do this with policy
routing, or by being careful with addressing plans... or their
applications could simply RH0 the traffic and take care of it
themselves.

(yes, I realize there probably a half dozen ways/reasons to do this
but it's one example that I'm certain some wierd enterprise op will
attempt at some point)

There might be one other use which was an original use for ipv4 source-routing:

I want to test a path between ATT and L3 and on to a L3 customer, I'm
a UU customer, I want to bounce the traffic off the CHI ATT device and
through an NYC UU device, I'd need to force routing to UU in NYC, then
ATT in CHI then on to the destination. (yes, this is also contrived,
sorry)

The point being that atleast 2 hops might be necessary, perhaps
more... Breaking this thruogh deprecation seems sketchy at best. In
the abstract for the draft:

  "The functionality provided by IPv6's Type 0 Routing Header can be
  exploited in order to achieve traffic amplification over a remote
  path for the purposes of generating denial-of-service traffic.  This
  document updates the IPv6 specification to deprecate the use of IPv6
  Type 0 Routing Headers, in light of this security concern. "

My point about deprecating something we really can't quantify usage of
is that I can pull examples from my hindquarters all day long, but I
can't (nor can anyone I suspect) really say if this is being used in
practice. That's a bad thing, we could be advocating breaking
something that folks depend upon, in closed communities off of the
'internet' where most of the concern seems to live (for this draft
atleast).

I think there are probably many other reasons that RH0 could be
considered 'bad', why is this one (amplification) the focus? why not
also get rid of icmp or udp or tcp? these can also all be use for
amplification attacks, yes?

I hesitate to get rid or something because of this sole reason, I
think another answer would be to make paying attention to it just
optional for routing gear (or all things, honestly I really only care
about routing gear, and so does this draft).

I'd also take issue, for many of the same reasons stated earlier with:

"The severity of this threat is considered to be sufficient to warrant
  deprecation of RH0 entirely"

from the draft, I don't think that deprecation is warranted in this
case, if it is than anything that can cause amplification attacks is
likely also in need of deprecation.

Allow consenting adults to do potentially harmful things is 'ok'.
Intermediate networks may decide to honor or not the 'potentially
harmful things', but that's their individual decision and shouldn't be
baked into the spec if at all possible.

-Chris

Thanks,
Vishwas

On 7/5/07, Christopher Morrow <[EMAIL PROTECTED]> wrote:
> On 7/2/07, Rémi Denis-Courmont <[EMAIL PROTECTED]> wrote:
> > Le jeudi 28 juin 2007, ext Bob Hinden a écrit :
> > > This starts a two week IPv6 working group last call on advancing
> > >
> > >       Title           : Deprecation of Type 0 Routing Headers in IPv6
> > >       Author(s)       : J. Abley, et al.
> > >       Filename        : draft-ietf-ipv6-deprecate-rh0-01.txt
> > >       Pages           : 9
> > >       Date            : 2007-6-28
> > >
> > > to Proposed Standard.  Please send substantive comments to the IPv6
> > > mailing list. Editorial comments can be sent to the authors.
> >
> > Document is fine with me. But what are the consequences with regards to
> > RFC3542? Should implementations stop parsing RH0 at that level as well?
>
> I fear that deprecating a part of the spec is going to lead to some
> confusion (as is shown above) and probably isn't the only option... I
> had wanted to send some longer feedback to jabley/ipv6@ but missed out
> it seems :(
>
> In short, I think that deprecation removes some functionality that
> people may want  to use (perhaps even for a good reason). There are
> other issues with removing this from the spec, like making another set
> of corner cases implementors will have to check for, ala cisco's
> 'protocols' bug of 2 years ago (just picking an example not picking on
> a vendor). Giving the network the option to ignore RH0 headers would
> have skipped us past this problem, and left the spec in good standing
> for the cases that might want to use it for good.
>
> -Chris
>


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

Reply via email to