RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues]

Dave Thaler <dthaler@windows.microsoft.com> Mon, 30 April 2007 17:32 UTC

Return-path: <ipv6-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZjH-0007Lr-JB; Mon, 30 Apr 2007 13:32:03 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiZjF-0007Lk-Fq for ipv6@ietf.org; Mon, 30 Apr 2007 13:32:01 -0400
Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiZjF-0001yD-1w for ipv6@ietf.org; Mon, 30 Apr 2007 13:32:01 -0400
Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.24; Mon, 30 Apr 2007 10:32:00 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.25; Mon, 30 Apr 2007 10:31:58 -0700
Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Apr 2007 10:31:57 -0700
x-mimeole: Produced By Microsoft Exchange V6.5
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 30 Apr 2007 10:30:57 -0700
Message-ID: <271CF87FD652F34DBF877CB0CB5D16FC05392DD8@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <Pine.LNX.4.64.0704301015180.11725@netcore.fi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues]
Thread-Index: AceK+0b6J87AkG2hS5alBpjg4y6JDAAUM17g
References: <462D4706.4000504@spaghetti.zurich.ibm.com> <462E7AB4.3050807@piuha.net><m2mz0xp6je.wl%gnn@neville-neil.com> <20070425093402.A30586@mignon.ki.iif.hu> <20070425141336.E95D522875@thrintun.hactrn.net> <462F7005.50700@sri.com><CE11116E-DF68-481D-AB30-E592C339CEFB@nokia.com> <46323659.2090406@piuha.net> <271CF87FD652F34DBF877CB0CB5D16FC053929E6@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <Pine.LNX.4.64.0704301015180.11725@netcore.fi>
From: Dave Thaler <dthaler@windows.microsoft.com>
To: Pekka Savola <pekkas@netcore.fi>
X-OriginalArrivalTime: 30 Apr 2007 17:31:57.0625 (UTC) FILETIME=[73E18290:01C78B4D]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>
Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing Headerissues]
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Errors-To: ipv6-bounces@ietf.org

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 started this thread, Windows
(and I think at least one other OS if I remember the PDF correctly)
supports RH for compliance, but already disables RH by default. 
Since that's already the deployed behavior of many hosts, I'd
support the disabled-by-default as the best choice.

-Dave

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Monday, April 30, 2007 12:43 AM
> To: Dave Thaler
> Cc: Jari Arkko; IETF IPv6 Mailing List
> Subject: RE: Question for IPv6 w.g. on [Re: IPv6 Type 0 Routing
> Headerissues]
> 
> Hi,
> 
> On Fri, 27 Apr 2007, Dave Thaler wrote:
> > Two scenarios that are much less harmful are
> > when there is only 1 address in only one RH0:
> > 1) when the intermediate destination address and the final
> > destination address are addresses of the same node.
> > 2) when the final destination address is equal to the
> > source address.
> >
> > In both cases, the intermediate destination isn't being
> > used as transit between two other nodes.  A sample use
> > case of the second scenario is for a round-trip
> > traceroute.
> 
> FWIW, I personally think 2) [turn off by default everywhere] seems
> like the best choice, but I think 1) [deprecate] would also be OK.  I
> wouldn't mind 4) but I wonder if it's worth the trouble.
> 
> Some IPv4 perspective:
> ----------------------
> 
> IPv4 specifications (RFC 1812) require source routing to be enabled on
> routers by default (a MUST).  IPv4 hosts MAY process routing headers
> (RFC 1122) and there are some specifications what should happen.  It
> seems that -- specification-wise -- the same attacks as exist for IPv6
> (multiple routing headers, multiple waypoints) are possible with IPv4
> as well.
> 
> IPv4 specifications also require that a host MUST reverse the routing
> header if they're a final recipient (leading to a symmetric return
> path). (IPv6 specs allow reversing only if RT header was
> authenticated)
> 
> Because attacks would likely be possible using v4 source routing as
> well -- unless implementation defaults differ significantly here --
> we should be able to walk, not run, to a decision.
> 
> Similarly, a decision should likely affect IPv4 as well.
> 
> Some operations perspective:
> ----------------------------
> 
> Please remember that using source routing for 'reverse path
> traceroute' is only possible if networks don't implement
> ingress/egress filtering.
> 
> As such, I cannot support the 'reverse path traceroute' usage scenario
> for source routing, because doing so shouldn't work in the first place
> in well-operated networks, and could be yet another roadblock to
> appropriate filtering.
> 
> The other scenario Dave mentions is AFAICS the one where type 2
> routing header was designed for, and could probably be used in that
> scenario as well, even if MIPv6 was not used.
> 
> A couple of folks mentioned using routing header for traffic path
> selection (in the middle of the network).  That also interferes with
> ingress/egress filtering, but not quite as badly.  This is probably
> mostly useful for research purposes and I'm having difficulty seeing a
> business case for doing this in production.
> 
> The reason why I'd prefer disabling instead of complete deprecation is
> that I can imagine use cases where source routing can be a useful
> diagnostics tool inside one administrative domain, and if we deprecate
> it, it's gone for good (unless we define a new type, and transition to
> it would take a long time).
> 
> On the other hand, given that these usage cases are rather limited, I
> don't think they're in wide use, and still cause problems for
> ingress/egress filters, I'm also ok with deprecation.
> 
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings


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