Subject: Fwd: New Version Notification for draft-baker-6man-multi-homed-host-02.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 22 Aug 2015 18:42:50 +0000

Hi. I have just posted -02 of this draft, as requested by the chairs. Brian and I have had a fairly extensive discussion regarding it with homenet, and some comments on this list, and have gone back to those that commented to ensure that we're addressing their concerns. Not every comment made seemed to us within our scope, which we understand to be about the host and the decisions it makes in SADR networks in which it has to make decisions. For those comments, we have invited (or in this comment invite) folks making them to make proposals of their own. However, we have tried to respond, in several cases using text offered, to comments folks made.

We invited commentary from 6man...

> Begin forwarded message:
> 
> From: <[email-masked]>
> Subject: New Version Notification for draft-baker-6man-multi-homed-host-02.txt
> Date: August 22, 2015 at 11:36:19 AM PDT
> To: "Brian E. Carpenter" <[email-masked]>, Fred Baker <[email-masked]>, Fred Baker <[email-masked]>, Brian Carpenter <[email-masked]>
> 
> 
> A new version of I-D, draft-baker-6man-multi-homed-host-02.txt
> has been successfully submitted by Fred Baker and posted to the
> IETF repository.
> 
> Name:		draft-baker-6man-multi-homed-host
> Revision:	02
> Title:		Host routing in a multi-prefix network
> Document date:	2015-08-21
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-baker-6man-multi-homed-host-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-baker-6man-multi-homed-host/
> Htmlized:       https://tools.ietf.org/html/draft-baker-6man-multi-homed-host-02
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-baker-6man-multi-homed-host-02
> 
> Abstract:
>   This note describes expected host behavior in a network that has more
>   than one prefix, each allocated by an upstream network that
>   implements BCP 38 filtering, when the host has multiple routers to
>   choose from.
> 
>   This may interact with source address selection in a given
>   implementation, but logically follows it - given that the network or
>   host is or appears to be multihomed with PA addresses, the host has
>   elected to use source address in a given prefix, and some but not all
>   neighboring routers are advertising that prefix in their RA PIOs, to
>   which router should a host present its transmission?
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: David Farmer <[email-masked]>
Date: Tue, 25 Aug 2015 03:24:51 -0500

There is an additional case where this is require; even if neither network implements BCP 38 ingress filtering, if one or both networks implements stateful firewall, especially with a default deny inbound policy, then the asymmetric traffic would be blocked by such firewall.

I'd suggest adding to the abstract;

   ...upstream network that implements BCP 38 filtering or stateful firewall, when the host...

And to the Introduction;

   ...upstream network that implements BCP 38 [RFC2827] filtering or stateful firewall, and in which the host...

   ...If the packet is sent to the wrong egress, it is liable to be discarded by the BCP 38 filter or the return packets are liable to be discarded by the stateful firewall, especially with a default deny inbound policy. ...

And to section 2.1, next to last paragraph;

...rather than a direct route originating with the host; this is at best inefficient, and at worst creates a routing asymmetry causing a policy violation for a stateful firewall if present.  Therefore the host...

I bring this up because unfortunately stateful firewall is probably way more prevalent than BCP 38 filtering.  Further, with the prevalence of WiFi, laptops and other devices with more than one active interface at the same time is likely the norm already, and if it's not it soon will be.  That is probably another issue to add to the intro too.

Thanks.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

> On Aug 22, 2015, at 13:42, Fred Baker (fred) <[email-masked]> wrote:
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 26 Aug 2015 08:27:06 +1200

But isn't hitting the stateful firewall a result of address selection,
not a result of source routing?

Regards
   Brian

---

From: David Farmer <[email-masked]>
Date: Tue, 25 Aug 2015 16:57:07 -0500

Yes and no,  if you have two networks, one with and one without stateful firewall then yes it is a question of which network you select.  If you select the one with stateful firewall and you send the packet out the other network you have an issue that the firewall will not have seen the exiting traffic and won't allow the return traffic through.  If you go the other way and select the network without stateful firewall and send the packet through the stateful firewall and it lets it through the return traffic will get to the original host.

However, if both networks have stateful firewall (allow any inside to go outside, and only allow outside traffic to the inside for initiated sessions). Then you select a source address from one of the two networks and if you send the packet out the correct default router you'll be fine.  However, if you send it out the wrong default router the the packet will be allowed out the wrong firewall, but because the return packet will come to the firewall for the other network and there is no associated connection established from is perspective the packet is dropped and the connection fails.  This wasn't because of any BCP38 type filter, it was because of the stateful firewall and the asymmetric traffic cause by sending the packet out the wrong default router (the default router for the other prefix that wasn't selected as part of source address selection).

In other words, if faced with BCP38 or stateful firewall you SHOULD send traffic to the router associated with the prefix that was selected during Source Address Selection.

> On Aug 25, 2015, at 15:27, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 27 Aug 2015 02:01:20 -0700

Fred,

Your draft says

   Modern hosts maintain a fair bit of history, in terms of what has
   historically worked or not worked for a given address or prefix and
   in some cases the effective window and MSS values for TCP or other
   protocols.

Can you please provide (and add to -03) any supporting evidence pointers, eg: any RFC/drafts
defining requirements for this piece or any paper/doc about any such implementation, - aka
anything that avoids me having to to RTFS of eg: leaked Microsoft Windows OS sources
(kidding).

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 28 Aug 2015 09:24:42 +1200

> anything that avoids me having to to RTFS of eg: leaked Microsoft Windows OS sources

I can't speak for Fred who drafted that text, but this is exactly the sort
of thing that connection managers do. They are normally separate from the
O/S stack of course.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Sep 2015 10:03:53 +1200

On 26/08/2015 09:57, David Farmer wrote:

<snip>

> In other words, if faced with BCP38 or stateful firewall you SHOULD send traffic to the router associated with the prefix that was selected during Source Address Selection.

I agree that a stateful firewall can in effect have the same impact as a BCP38
filter. We should probably mention that in the draft. However, in free space
a host does not know about either of them, or whether the local routing cloud
supports SADR, so the practical result is that *in all circumstances* you
SHOULD send traffic to a router associated with the source prefix.

   Brian