> Bob Hinden wrote:
> > [trimming this to just the IPv6 w.g.]
> >
> > We think the question for the IPv6 working group on this topic is does
> > the working group want to do anything to address the issues raised about
> > the Type 0 routing header. Possible actions include:
> >
> > 1) Depreca
> On Apr 26, 2007, at 17:17, james woodyatt wrote:
> >
> > [...] I still don't think type code *ZERO* is the wrong choice [...].
>
> Oops. This should have read, "I still think type code *ZERO* is the
> wrong choice..." Sorry for any confusion.
don't worry, the world is in panic like 1
even though Japanese, itojun2.0 is much like Theo so bare with me.
i will use quite a language, so it's X-rated.
and for those who didn't know, theo finally plan about enabling INET6
on cvs.openbsd.org and studying jinmei/shima/qingli book.
our 15 years of e
> he is also ICHIRO) and me (king of v6, jinmei beats me in careful
> spec reading because i'm spine-coder and nanosleep guy)
> to make "IPv6 samurais", which is IPv6.
$s/IPv6\.$/KAME./
it's miracle that i need to correct only one typo.
my hands are shaki
> > 1) Deprecate all usage of RH0
> > 2) Recommend that RH0 support be off by default in hosts and routers
> > 3) Recommend that RH0 support be off by default in hosts
> > 4) Limit it's usage to one RH0 per IPv6 packet and limit the number
> > of addresses in one RH0.
>
> My preference is 2 or
i don't understand, rthdr0 must be killed, grilled, diced into million
pieces. say farewell. you did not do my exercise even:
- how many hops you can make w/ a packet sized 1280?
itojun
> Manfredi, Albert E wrote:
> > > -Original Message-
> > > From: Tony Hain
> I am a bit surprised that the security problems with the routing header
> come as some sort of revelation at this stage. The intent, as I recall,
yup, it's such 1992 problem. hinden and kame needs harakiri.
> handy. My recollection of a conversation with Steve on this topic back
> in
again reading from backwards.
> Round-trip traceroute is useful inside intra-domain environments as
> you note, where ingress filtering isn't generally deployed. Hence
> it works in many places today and it can be very useful for debugging.
>
> Also, as noted in the original PDF that st
> now, in KAME we meant to make t-shirt
>
> "code then spec, not spec then code'
Now T-shirt is available at http://www.kame.net/.
itojun
IETF IPv6 working group mailing list
ipv6@ietf.org
A
> > now, in KAME we meant to make t-shirt
> >
> > "code then spec, not spec then code'
>
> Now T-shirt is available at http://www.kame.net/.
see http://www.natisbad.org/ for the summary of the problem as well
as list of link to the press coverages.
> On Mon, Apr 30, 2007 at 05:43:04PM -0700, james woodyatt wrote:
> > I
> > further recommend the draft standards be amended to require that RH0
> > be rejected with an ICMP error when received at the first destination
> > and dropped silently in all other cases. This will allow operators
> We (me and George Neville-Neil) haveve just submitted an I-D on type 0
> routing header processing. In the meantime, it's available here:
>
> http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-rtheader-00.txt
>
> Its approach is "disable by default, but type 0 routing header is
> still a pa
sorry, with flood of emails and phonecalls i really cannot keep up.
it could be duplicate of comments that were made by various people.
i'm calm as stillwater now, so it is PG13 rating :-)
> > The above sentences far more closely resemble what I meant to write,
> > compa
> - packet filters MUST have filtering language/syntax/whatever that
> supports rthdr0. openbsd guys are working on it - PF syntax will be
> annotated with new rule. see May 8 entry by [EMAIL PROTECTED] at
> http://opengrok.creo.hu/openbsd/history/src/sys/net/. more
> Deprecating RH0 seems to be the only reasonable choice. I do not get
> why some people want a 'disable by default' solution to this problem.
> Do we need to explain one more time why RH0 MUST NOT be turned on ?
cannot agree more. you helped me sleep tight.
itojun
-
> I understand Itojun's suggestion that we can have a RH7 that will
> allow useful source routing without the danger associated with RH0.
> This sounds like a very good idea. However, realistically, I suspect
> that even if the RH7 standard was fully specified tomorrow, we would
> be waiting more
> On 16-mei-2007, at 10:05, Ebalard, Arnaud 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:
> > > 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
> > as posted earlier, i cannot really sleep tight until the very last
> > machine on the planet get patched. root DNS servers as well as all
> > trans-ocean links (both IPv4 and IPv6) are at stake. if this does
> > not
> > scare you enough, quit your job immediately.
>
> Well,
> Not sure why this hasn't gotten to the list yet, but here it is again.
> >
> > Title : Deprecation of Type 0 Routing Headers in IPv6
> > Author(s) : J. Abley, et al.
> > Filename: draft-ietf-ipv6-deprecate-rh0-00.txt
> > Pages : 7
> > Date
> > I added a reference to the ipv6 security draft.
> I had brought out this amplification attack way back in January of
> 2006 though without the big RED flags, that is the reason I wanted to
> own up the responsibility. :))
i've got a comment from IPv6 ready logo team (iirc it is sub-co
> At the time of bringing up the amplification attacks i had also
> brought up the issue of
> http://tools.ietf.org/html/draft-manral-v6ops-tiny-fragments-issues-02 .
>
> I would want to know if this issue needs to looked further by IPv6.
my take on this is that, for non-final fragment, t
> > my take on this is that, for non-final fragment, the packet size must
> > not be smaller than 1280 bytes. there's no valid use for smaller
> > fragments (unless you have special network with MTU < 1280).
> I agree to the solution. If we get more people talking about the need
> for this, we
> As part of the deprecation effort, does it also make sense to
> update RFC 3542 (Advanced API) to remove the references to Type 0
> routing header?
we may want to remove references to rthdr0, but section 7 (Routing
Header) may be useful for rthdr7 (non-disturbing version of sourc
> >On Wed, May 16, 2007 at 03:54:48PM -0700, Dow Street wrote:
> >> I think the new draft is too extreme in its mitigation approach, and
> >> would favor the "disable by default" option instead.
> >
> >I think the new draft is too soft in it's mitigation approach, and would
> >favour language that
i agree with jinmei 90%, but i would like to make a single comment:
>This attack is particularly serious in that it affects the entire
>path between the two exploited nodes, not only the nodes themselves
>or their local networks. The same attack can be performed using
>the
> > i'm writing it with an assumption that nodes would perform ingress
> > filtering against packets with source-routing header properly - yup,
> > they CANNOT perform ingress filtering due to the existence and the
> > nature of the source-routing. it is natural for source-routed p
> I would prefer to not split too many hairs. I believe we want RH0
> off, and if that is the case we should clearly state that:
>
> IPv6 nodes MUST NOT originate packets containing RH0 and SHOULD return
> a Parameter Problem ICMPv6 message with code of 2 Unrecognized IPv6
> Option Encounte
28 matches
Mail list logo
