Re: [homenet] I-D Action: draft-haddad-homenet-multihomed-00

[Lorenzo Colitti <[e-mail]>]

On Wed, Oct 24, 2012 at 12:20 AM, Michael Thomas <[e-mail]> wrote:

> On 10/22/2012 08:35 PM, Lorenzo Colitti wrote:
>
>  On Tue, Oct 23, 2012 at 4:18 AM, Michael Thomas <[e-mail] <mailto:
>> [e-mail]>> wrote:
>>
>>     No, sorry. Corporate VPN's using v6 and the lack of a coherent source
>> address selection mechanism causes breakage in bizarre and unpredictable
>> ways. You are not going to get the results you hope for if your mac uses an
>> ISP prefix to get back inside the corpro firewall, uRPF if nothing else.
>> SLAAC changes a lot of things over v4.
>>
>>
>> VPN clients already modify the routing table to ensure traffic going
>> through the VPN goes through the VPN, to enforce policies around split
>> tunneling, and so on. Mine even monitors the routing table for changes so
>> it can act on them.
>>
>
> Routing is irrelevant.


Sorry, but no. Routing is not irrelevant:

   Rule 5: Prefer outgoing interface.
   If SA is assigned to the interface that will be used to send to D and
   SB is assigned to a different interface, then prefer SA.  Similarly,
   if SB is assigned to the interface that will be used to send to D and
   SA is assigned to a different interface, then prefer SB.

The choice of outgoing interface is a routing decision and thus the routing
table can be used to influence source address selection.


> Can you explain why this behaviour, combined with the "prefer matching
>> interface" rule in RFC 3484, is not sufficient? If not, then there is no
>> problem to solve here.
>>
>
> Your ISP gives you 2001:xxxx:: via SLAAC. Your employer gives you
> 2000::, but also has 2001:yyyy::. You connect to a server on 2001:yyyy::.


You missed the "your employer configures your routing table to point
2000::/64 and 2001:yyyy::/64 to the tunnel interface" step. Your employer
has to configure your routing table today for IPv4 (either a default route
or more-specific routes to private addresses for split tunneling). In IPv6
said employer needs to give you more specifics.


> Your 3484 v6 stack picks 2001:xxxx for the source address.


Nope. A routing lookup tells the kernel that the tunnel interface will be
used to send to that destination, and the RFC3484 stack will pick 2000:: as
the source address due to rule 5 above (note that you don't need to invoke
5.5 in RFC 6724 to make this work; RFC3484 is sufficient).


> Hilarity ensues:

1) the packet gets rejected via uRPF
> 2) the return packet splats against the inside firewall since it's not
> allowed outside
> 3) the packet makes it outside unarmored with sad faces from the security
> team


As James said, none of this happens.

Now - if we want to make this in a routed network where the VPN tunnel is
not terminated on the device itself, then RFC 3484/RFC6724 are not
sufficient. But that problem not substantially different to the "multihomed
with two ISPs problem", which we are trying to solve anyway. I believe this
can be solved properly using source/destination routing.