Subject: Re: draft-ietf-ipv6-deprecate-rh0-01-candidate-00

From: "Ebalard, Arnaud" <[email-masked]>
Date: Thu, 7 Jun 2007 08:19:44 +0200

Hi,

Le 7 juin 07 à 01:31, Tony Hain a écrit :

> There is no 'amplification', so the abstract is just wrong.
No, you are wrong. At least, read that :

http://www1.ietf.org/mail-archive/web/ipv6/current/msg07331.html

> The best this can do is route a single stream around policy;
Again, wrong.

> and for some the ability to route around the brokenness of an ISP
> in anti-competitive mode is a value, not a drawback.
Can you point us to the tool/device you are using to do that.

> The crap in the document about an anycast destination being
> an amplification shows how little understanding
And your sentence little reading of the document.

> Anycast == 'unicast to the nearest instance'
RH0 mechanism allows people to bypass that.

>  again I say the hysteria needs to stop.
True

> There is no reason to preclude nodes from processing RH0 packets.  
> If you
> have to say something say that 'hosts must not forward' else they  
> become
> routers. [...]
Already said. *BSD did it wrong, but that's just a tiny part of the  
whole story.

Cheers,

a+

-- Arnaud Ebalard
EADS Innovation Works - IT Sec Research Engineer
PGP KeyID:047A5026 FingerPrint:47EB85FEB99AAB85FD0946F30255957C047A5026

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

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Jun 2007 09:40:45 -0700

> http://www1.ietf.org/mail-archive/web/ipv6/current/msg07331.html

I read it around the time it was sent, and it says that you were able to
reflect the same packet back multiple times. That does not amplify it to
multiple destinations as the current document claims, or amplify the amount
of bits in flight at any given time. 

> > The best this can do is route a single stream around policy;

It is still a single stream, and your assumption about policy is that a
packet should traverse a single link at most once. As I said, it routes a
single stream around policy. 

> And your sentence little reading of the document.

I will admit I only read it through once, and given the overall agitation
over the hysteria related to this topic I likely missed subtle points. That
said, this entire effort is about preventing opportunities, there is nothing
that is new and the same mitigation that is done for IPv4 routing headers
works here.

> RH0 mechanism allows people to bypass that.

It still only goes to the 'nearest instance', just the 't see calls to deprecate TCP
... 

Section 7
This presentation resulted in widespread publicity for the risks associated
with RH0.

s/publicity/hysteria

Tony

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Jun 2007 09:40:45 -0700

> RH0 mechanism allows people to bypass that.

It still only goes to the 'nearest instance', just the one closest to the
RH0 target rather than the source. That is not an amplification, it is
bypassing local policy.

> Already said. *BSD did it wrong, but that's just a tiny part of the

So we are in the mode of changing specs when an implementation got it
wrong??? If MSFT had been the one, wouldn't the response be screaming about
how clueless they are about following specs?

A device that forwards L3 packets not addressed to itself is a router. If a
device is not expected to forward packets, it must drop RH0 packets where
the next hop is other than self. 

Since RH0 processing in the host is about dealing with ingress filtering to
reach an alternate address, and we now have mobility to do that, I have no
problem with removing the ability for a host to process a received RH0
packet. I do have a problem with trying to kill it outright because that
precludes a metro/geo aggregation environment where the source needs to
select transit across the local exchange fabric.

Tony

one closest to the
RH0 target rather than the source. That is not an amplification, it is
bypassing local policy.

> Already said. *BSD did it wrong, but that's just a tiny part of the

So we are in the mode of changing specs when an implementation got it
wrong??? If MSFT had been the one, wouldn't the response be screaming about
how clueless they are about following specs?

A device that forwards L3 packets not addressed to itself is a router. If a
device is not expected to forward packets, it must drop RH0 packets where
the next hop is other than self. 

Since RH0 processing in the host is about dealing with ingress filtering to
reach an alternate address, and we now have mobility to do that, I have no
problem with removing the ability for a host to process a received RH0
packet. I do have a problem with trying to kill it outright because that
precludes a metro/geo aggregation environment where the source needs to
select transit across the local exchange fabric.

Tony

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 08 Jun 2007 02:26:04 +0900

At Thu, 7 Jun 2007 08:19:44 +0200,

> Already said. *BSD did it wrong, but that's just a tiny part of the  

Please precisely define "wrong" here.  And however "wrong" it is (or
even whether or not it's wrong), host vs router is irrelevant to the
main point in this context (I thought you understood this, so I'm
wondering why you bother to refer to the irrelevant point...).  IMO
it's just misleading to mention the behavior of a specific
implementation using the unclear term.

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