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

From: "Christian Huitema" <[email-masked]>
Date: Mon, 25 Mar 2002 09:26:45 -0800

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. However, a standard sanity
check is that the source address should belong to an address prefix that
is reachable through the originating domain. 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.

> 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. There is a
reason why the recommended policy is "ingress filtering", not blind "RPF
everywhere."

-- Christian Huitema

---

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Mar 2002 19:44:51 +0200 (EET)

On Mon, 25 Mar 2002, Christian Huitema wrote:
> inter-domain routing is widely asymmetric. 

True.

> However, a standard sanity
> 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

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

> inter-domain border is going to break much more than Teredo. 

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

> There is a

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