Re: Source address selection insufficient?

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 3-mrt-04, at 6:29, Erik Nordmark wrote:

>              /-- ( A ) ---(      ) --- ( C ) --\
>    X (site X)             ( IPv6 )              (Site Y) Y
>              \-- ( B ) ---(      ) --- ( D ) --/

> This has 4 locator pairs:
> 	A:X-C:Y
> 	A:X-D:Y
> 	B:X-C:Y
> 	B:X-D:Y

Ugh, is it just me or is the A:X notation (rather than X:A) very 
counter-intuitive?

> The set of locator pairs that work when sending out from site X
> might be A:X-C:Y and B:X-D:Y
> but the set of locator pairs that work when sending from site Y might
> be the other two: A:X-D:Y and B:X-C:Y.

What you are saying is that X wants to reach Y over either the path 
A->C (1) or the path B->D (2), while in the other direction the path is 
D->A (3) or C->B (4). The address permutations in the packets are then 
as follows (!I means ingress filtered):

address pair	X->Y direction	Y->X direction
A/C				(1)					(3) !I
A/D				(2) !I				(3)
B/C				(1) !I				(4)
B/D				(2)					(4) !I

> Thus the intersection of the two ingress filtering constraints is the 
> empty set.

:-(

This means our address agility mechanisms must support packet flow 
where the src/dst addresses in packets in one direction don't 
correspond to the src/dst addresses in opposite direction. In the above 
example X may send out packets with A/C while Y responds with packets 
containing D/B.

Unfortunately this still breaks all non-address agile protocols, most 
notably current TCP and UDP but also many proposed solutions in their 
compatible or negotiation phase.

> This can happen due to normal routing as far as I can tell.

> Am I missing something?

The only way this can happen during "normal" routing is when the two 
destination addresses for a correspondent are routed differently. When 
this isn't the case (for instance, when a default route is in effect) 
the problem should only occur when there are outages but current TCP 
and UDP are dead in the water in that case anyway. We have to look at 
the possibilities of setting up new sessions (with a multihoming 
solution in effect) under these circumstances, though.

I guess this means that trying different source addresses CAN be 
sufficient but it's far from ideal because it can't live together with 
existing traffic engineering techniques.

But maybe the problem isn't as bad as it would seem at first glance: 
for small sites, source address based routing is fairly trivial and it 
provides decent overal traffic engineering (although individual streams 
may suffer) while only larger sites are going to run BGP in order to do 
traditional traffic engineering anyway, and presumably, those sites are 
in the position to get ingress filtering relaxed. (We need to document 
this very well at some point because this is still imcompatible with 
ingress filtering further downstream.)