Re: (ngtrans) RE: Shipworm-05 comments #4: anycast and RPF

Pekka Savola <pekkas@netcore.fi> Mon, 25 March 2002 17:49 UTC

Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22400 for <ngtrans-archive@lists.ietf.org>; Mon, 25 Mar 2002 12:49:15 -0500 (EST)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00393; Mon, 25 Mar 2002 10:45:44 -0700 (MST)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10765; Mon, 25 Mar 2002 09:45:35 -0800 (PST)
Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PHiwKL006078 for <ngtrans-dist@sunroof.eng.sun.com>; Mon, 25 Mar 2002 09:44:58 -0800 (PST)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PHiwqs006077 for ngtrans-dist; Mon, 25 Mar 2002 09:44:58 -0800 (PST)
X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ngtrans@sunroof.eng.sun.com using -f
Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PHitKL006070 for <ngtrans@sunroof.eng.sun.com>; Mon, 25 Mar 2002 09:44:56 -0800 (PST)
Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL, v2.1p1) with ESMTP id JAA07124 for <ngtrans@sunroof.eng.sun.com>; Mon, 25 Mar 2002 09:44:57 -0800 (PST)
Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29900 for <ngtrans@sunroof.eng.sun.com>; Mon, 25 Mar 2002 10:44:55 -0700 (MST)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2PHipB24352; Mon, 25 Mar 2002 19:44:51 +0200
Date: Mon, 25 Mar 2002 19:44:51 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Christian Huitema <huitema@windows.microsoft.com>
cc: ngtrans@sunroof.eng.sun.com
Subject: Re: (ngtrans) RE: Shipworm-05 comments #4: anycast and RPF
In-Reply-To: <F66A04C29AD9034A8205949AD0C90104032701A8@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Message-ID: <Pine.LNX.4.44.0203251934440.24212-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Pekka Savola <pekkas@netcore.fi>

On Mon, 25 Mar 2002, Christian Huitema wrote:
> Pekka did not highlight these comments, but they are important to
> discuss. One of the strongest pushback from the IESG reviewers concerned
> the interaction between ingress filtering and the use of a single IPv4
> source address from all relays and servers. The use of a single source
> address is necessary if we want to actually go through all types of NAT,
> but there are clearly some limitations, which I tried to document in the
> revised spec.
> 
> > 4.2.1   Deployment in the Global Teredo Network
> > 
> > Teredo Network servers and relays SHOULD only be deployed in an
> > autonomous system if the autonomous system is ready to announce a
> > route to the Global Teredo IPV4 anycast prefix to all its peers.
> > 
> > ==> I see zero reason for this requirement.
> 
> The requirement stems from the practice of ingress filtering between
> autonomous systems. Such filtering cannot solely be based on RPF, since
> inter-domain routing is widely asymmetric. 

True.

> However, a standard sanity
> check is that the source address should belong to an address prefix that
> is reachable through the originating domain. 

Is it?  I haven't heard of this, on a _global_ scale.

What is used now and then, though, are static access lists where allowed 
source addresses are listed.  These are often used when w/ static routes 
or simpler BGP configurations: from the direction of the customer to the 
ISP, for example.  But I don't think anyone something like this from the 
direction of the Internet.

(Another failure mode is if the operator advertising the anycast address 
forgets what it is and filters it out if in the source address at the 
border, as a rogue use of your own addresses.)

> Teredo packets cannot pass
> the inter-domain ingress filtering test if the originating domain does
> not advertise reachability of the Global Teredo IPV4 anycast prefix.

Practically I don't think this is used as often, see above.

> > 6.8     What about anycast routing and ingress filtering?
> > ... 
> > A network operator who is not ready to announce the service to the
> > whole Internet has the option of operating a specific Teredo
> > networks, using its own set of topologically correct addresses and
> > prefixes. Some amount of reliability and efficiency can still be
> > achieved if each specific network is served by an adequate number of
> > servers and relays.
> > 
> > ==> not so: if RPF is enabled and and you have a Shipworm server in
> your
> > network, the end result always seems to be disastrous no matter what
> you
> > do.  The problem is that packets from the other servers use the same
> > anycast address as source as you're using in your own server, and
> packets
> > are thus dropped at the border.  Advertising to the Internet etc.
> won't
> > help.
> 
> This is the same problem as any multi-homed domain. Suppose that a site
> X with address x.x.x.x/n is multihomed between provider A and provider
> B. Depending on local decisions at site X, the packets will be routed
> through either A or B, with exactly the same effect. Enabling RPF at an
> inter-domain border is going to break much more than Teredo. 

I agree very much on the non-applicability of RPF.

> There is a
> reason why the recommended policy is "ingress filtering", not blind "RPF
> everywhere."

Yes: but the policy in the draft should be clarified.  "uRPF must not be
used in any border where there may be a Relay/Server" or in IPv6 RPF case,
"Any Teredo Clients or Servers using the global prefix" (I think..).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords