Re: failure detection

[Paul Jakma <paul@clubi.ie>]

On Tue, 30 Aug 2005, Erik Nordmark wrote:

> Paul Jakma wrote:
>
> > But SAS is inherently tied in with routing. Let it do its magic.
>
> According to which RFC? ;-)

Don't think there are any standards-track for IPv4, not even sure if 
there are informational ones. There is something for IPv6 isn't 
there? However, in implementation, that tends to be how things are 
done in order to be able to get packets to the right place.

> The source address selection is influenced by which interface is 
> used (I think RFC 3484 says that), but I know of no text in an RFC 
> that ties the source address selection to the first hop router 
> being used.

Indeed, but it makes sense, and that's generally how source is 
selected for unspecified packets. Pick the nexthop, then pick an 
appropriate source according to connected network being output to 
for that next-hop.

> Yes, draft-huitema already points this out.

Excellent ;)

> But here is where the out-of-the-box behavior of the hosts doesn't 
> match your expectations. The host will pick a source address that 
> is appropriate for the network interface,

Right.

> but apart from that there isn't any correlation between the source 
> address and the 1st hop router it is using.

In practice, there likely is a very strong correlation between the 
output interface and the address(es) on that interface, the latter of 
which were used to decide which interface is appropriate for the 
chosen next-hop. So in practice, there's a very strong correlation 
between next-hop used and source address selected for addr-any 
sockets sending packets that will go via that next-hop.

You *can* setup really strange scenarios where you use a next-hop for 
a route (eg your default) for which none of your interfaces have 
addresses which they share with that nexthop. But then you must 
specify the output interface manually anyway, and hence you can 
easily specify the appropriate source too at that stage.

> But we also need to capture the slightly larger case where there 
> might be a handful of routers in the site, thus the host might not 
> be directly attached to the border routers.

Right, but there still must be a router attached to same network as 
one of its interfaces.

> draft-huitema suggests different approaches for doing this, and the 
> simplest one for multiple border routers is to have the border 
> routers setup tunnels between themselves so that they can pass 
> packets to an exit that is appropriate for the source address. In 
> the case of the border routers being on the same link, they can 
> discover each other automatically, but manual configuration might 
> be needed when such discovery isn't possible.

Tunnels between routers in the /same/ IGP AS does not seem ideal. 
Just distribute the required source-routing information to those 
routers which need to be aware of it, eg using Opaque-LSAs. Have each 
border router originate a "I am a packet-sink for address-range X" 
LSA. Would require OSPF though - which isn't ideal.

A simple standalone flooding protocol, to distribute knowledge of 
available prefixes to interior and work alongside RAs, might be an 
idea.

> This could be combined with some automatic protocol by which the 
> border routers can inform the interior routers of which prefixes 
> have failed, and the interior routers can advertise that in their 
> RAs. (Something like an extension to RFC 2894 "router renumbering 
> protocol" could be made to work.) However, such a protocol requires 
> some security configuration, otherwise anybody on the Internet 
> could use this to reconfigure the RAs your interior routers send.

One would hope this would this be a link-local protocol at least.. 
preferably with an HMAC or IPSec AH.

> Thus I don't think we can assume that some such, not yet invented 
> mechanism for propagating information from border routers to 
> interior routers, exist.

> This leads me to conclude that we can't assume that source address 
> selection can solve the ingress filtering interaction.

I disagree with this. Just because the required router protocol 
infrastructure does not exist is not a good reason to try bypass 
developing such infrastructure.

If there's customer demand for IPv6 multihoming (eg cause of shim6 ;) 
) and then customers require facilities for steering packets to right 
ISP according to the source, and require a way to reflect 
prefix-availability AS-wide, the router vendors will respond.

> In both the single and multiple border router cases, the host will 
> need to pick a source address before the packet leaves the host. 
> The source-based routing in the border router(s) ensure that when 
> both paths are working, the packet will leave on an exit where it 
> doesn't get filtered out.

Right.

And surely it's more sane to have border-routers be able to affect 
which prefixes are posted as 'available' by interior routers within 
an AS, to the hosts *before* they ever try pick a source?

That prefix-propogation protocol could, at the same time, be used to 
install the required source-routes in the routers concerned to direct 
the packets to the border-router appropriate for the prefix 
concerned.

That seems achievable and also more proactive and sane than having 
hosts sending a multitude of packets with every combination of source 
and destination they have to hand, simply for the reason that "well, 
the routers don't have that mechanism yet".

I don't understand why a protocol for /tomorrows/ networks should be 
trying to hack around a lack of functionality in /todays/ interior 
routing, when the correct place is obviously to extend capabilities 
of interior routing (and IPv6 RAs).

> However, when there is a failure then presumably the border routers 
> will send packets up the exits they know are working; in any case, 
> after a failure towards ISP1 packets with the source address from 
> ISP1's prefix will not make it through (either they are sent out 
> the exit to ISP1 and experience the failure, or they are sent out 
> the exit to ISP2 and are ingress filtered away).

> As a result, the host must be prepared to try sending packets with 
> different source addresses.

How do you reach that conclusion? The conclusion I would draw:

You need your routers to do what they're supposed to do: Direct 
packets to the appropriate next-hop. If that will require 
source-prefix routing and means to distribute source-specific routes, 
then let the routing area figure that out.

It could be done as a vendor specific hack with opaque LSAs pretty 
easily.

> Did it work without any manual configuration of the host?

*hosts*, and yes it did.

   ISP1-gw  ISP2-gw
        |    |
        |    |
        R    R
        |    |
     -----------
      | | | | |
       <hosts>

The hosts were configured with an address for each PA range, the 
routers did the magic.

> I think that is the crux of the matter; we can automate this for the single 
> SOHO router case by adding a "failed" notion to the prefixes in the RAs.

Positive signalling of failure is problematic though.

> But slightly larger networks would require a secure way for border 
> routers to inform interior routers, which I think requires 
> configuring some security somewhere.

Sure.

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
Integrity has no need for rules.