Subject: Re: (ngtrans) shipworm, 6to4 and anycast [...]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Feb 2002 12:05:57 +0100

Pekka Savola wrote:
> 
> On Thu, 31 Jan 2002, Erik Nordmark wrote:
> > The spec is also "missing" 2) as far as I can tell.
> > Looking for "source" in RFC 3068 doesn't show any place where it
> > talkes about what the IPv4 source address should be for packets encapsulated
> > by a relay. It does say in passing something about the IPv4 source address
> > for packets sent by 6to4 routers but that's it.
> 
> Ok, it isn't specified, I took it for granted.

And I never did. I'd assumed that as always, anycast is
only meaningful as a destination address, and that the specific
IPv4 address will be used in response.

> 
> (An interesting detail: RFC3056 section 3 second paragraph would require
> this for a subset of packets if IPv6 anycast address would not be, well,
> IPv6 anycast address that couldn't be used as the source [some relays are
> using broken anycast implementation, and they would be required to use
> 192.88.99.1 as source.)

I don't quite understand the syntax or semantics of your sentence, but if a
packet is going from a relay to a standard 6to4 router (or to a host playing 
the role of a 6to4 router), the *destination* IPv6 address will be 
2002:destIPv4addr/48, which meets the condition in that paragraph. The 
source IPv6 address and source IPv4 address will be completely independent,
in the general case, since the source IPv6 address will be native; that's why 
the packet is coming from a relay.

So I see nothing to suggest that the IPv4 anycast address is required
to be used as a source address.

> 
> > So what is the correct thing to do for 6to4?
> > Are there any benefits to use the 6to4 anycast as a source address for 6to4?
> 
> IPv4 anycast could be used to identify the relay routers. (Either from
> packets-on-the wire, or in security checks [this is mostly useful only if
> you assume that most IPv4 nodes cannot spoof their sources, or spoofing
> the IPv4 anycast is more difficult])

I see no reason why spoofing an anycast source address is more difficult. 

> 
> It appears that there are a few potential drawbacks, pointed out before
> here:
>  - RPF checks might fail
>    * this happens when RPF is being performed where the path to the
>      closest relay and other relays would be different where RPF is
>      applied.
>    * basically this often applies (the list is probably not exhaustive):
>      - LAN has a local relay and RPF is applied at first-hop level
>        (note: all LAN's connected to the same router are busted)
>      - the organization has its own relay and RPF is at organization-ISP
>        border
>      - ISP has a relay and RPF is applied at ISP-ISP or Transit level
>      - organization/ISP/.. is multihomed and sees different relays from
>        different connections
>  - Tracing where the relay is, is more difficult
>    * route aggregator, origin router-id etc. can tell this at some
>      management level
>    * ping6 <ipv6-anycast> reveals the native IPv6 address of the relay
>      immediately, so I don't think this is significant, at least for IPv6
>      users
>  - Others?

That's enough I think :-)
> 
> Noticeably, RPF does not work well with proper IPv4 "anycast".. I wonder
> whether that's an obstruction we have to be careful about.

Well, it's another nail in the coffin of anycast source addresses in general.

> 
> (Personally I like static access lists better than RPF, and that will be
> much easier due to aggregation than with IPv4 too.)

Yes, but for filtering spoofed, relayed, 6to4 packets, it's the IPv4
address that has to be filtered. My belief, as I've said before, is that
this can only be done by explicitly accepting/rejecting individual
relays into an ACL, if you aren't willing to accept the spoofing risk.
And this isn't a protocol issue.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Fri, 1 Feb 2002 13:27:14 +0200 (EET)

> to be used as a source address.

Perhaps my syntax was a bit too complex.. if it existed ;-)

What I meant that if you 'ping6 2002:c058:6301::' and the address 
_wouldn't_ be set up as anycast, or the implementation would be buggy, the 
replies back would use  2002:c058:6301:: which MUST have 192.88.99.1 as 
source.

Ifs and ifs.. 

> I see no reason why spoofing an anycast source address is more difficult. 

It might be, a bit .. but not enough to make it significant.  E.g.  
consider mit.edu with 18.0.0.0/8.  Hypotethically, they filtering _could_
be performed only at the university-isp border or
university-facility(whatever) border.  Spoofing inside that would be still
possible.  But as this spoofing would be very restricted (and only even
remotely useful in very sites) I don't think it counts for much.

> address that has to be filtered.

True.

> My belief, as I've said before, is that

I believe this has scaling problems (you don't know whose legitimate
traffic you're going to block).. this would only work with more specific
routes than 2002::/16 or all relays peering with each other via e.g. ebgp
multihop an telling these more specifics.  But we've been over this too 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