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

From: David Farmer <[email-masked]>
Date: Tue, 01 Sep 2015 17:03:58 -0500

On 8/31/15 17:03 , Brian E Carpenter wrote:
> 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

It might not hurt to list uRPF, stateful firewall, SADR, etc... 
Basically any keywords that trigger the importance of this to people.

So why am I beating this horse?  I get why we don't want this to update 
the base IPv6 standards, but if this doesn't, then people have to 
understand why it is critically important to implement this.  I said 
previously we need a strong applicability statement.

We need to be abundantly clear this isn't just about BCP38 which far too 
few people actually implement anyway, but is about virtually any 
security applied at the packet level, uRPF, SADR, but most importantly 
stateful firewall.  I say "most importantly stateful firewall," because 
the security people seem to go around the Internet planting (stateful) 
firewalls like Johnny Frickin Appleseed.  And I want everyone that 
thinks that is a good thing to realize that they have to make sure this 
gets implemented.

So, I'd like stateful firewall to get equal billing in the abstract with 
BCP38.

Thanks, and I'll stop now.

-- 
================================================
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
================================================

---

From: james woodyatt <[email-masked]>
Date: Tue, 1 Sep 2015 16:51:31 -0700

On Sep 1, 2015, at 15:03, David Farmer <[email-masked]> wrote:
> It might not hurt to list uRPF, stateful firewall, SADR, etc... Basically any keywords that trigger the importance of this to people.
> 
> […] I say "most importantly stateful firewall," because the security people seem to go around the Internet planting (stateful) firewalls like Johnny Frickin Appleseed.  And I want everyone that thinks that is a good thing to realize that they have to make sure this gets implemented.
> 
> So, I'd like stateful firewall to get equal billing in the abstract with BCP38.

So we have Basic Requirements for IPv6 Customer Edge Routers [RFC 7084] which issues these two security requirements:

>> S-1:  The IPv6 CE router SHOULD support [RFC6092].   […]
>> S-2:  The IPv6 CE router SHOULD support ingress filtering in accordance with BCP 38 [RFC2827].  […]

I expect most RFC 7084 home gateways conform with S-2 and apply BCP 38 filtering. I’m not aware of any that don’t.

However, for grins, I reviewed the recommendation about this in RFC 6092 to see if there is something specific about that particular kind of stateful firewall that could be relevant here. It looks like REC-5 is the only one.

>> REC-5   Outbound packets MUST NOT be forwarded if the source address
>>            in their outer IPv6 header does not have a unicast prefix
>>            configured for use by globally reachable nodes on the
>>            interior network.

Technically, it wouldn’t be a violation of this recommendation if a firewall forwards outbound packets having source addresses in globally unique prefixes advertised by other default gateways on the interior network. There is nothing in RFC 6092 to recommend blocking those packets, but we shouldn’t expect it in practice: their return path probably comes back through another RFC 6092 gateway, which can only forward those inbound packets if the “transparent mode” of operation is enabled or there is an unspecified state distribution protocol in operation, which RFC 6092 doesn’t mention at all.

It’s important to note here that REC-49 says the default configuration for RFC 6092 firewalls MAY be for transparent mode to be disabled. So expect people to do that when they care more about minimizing attack surfaces than enabling networks to remain usable while people try to do something obvious and natural like switch service providers gracefully. There are governments that have policies about this.

I’m unaware of any RFC 7084 home gateways that are able to coordinate their simple security functions so that an outbound flow through any router will create appropriate state for inbound packets in all the firewalls on every return path. I doubt anybody has even bothered to consider that problem worth solving.

Shorter james: even if RFC 7084 gateways only conform with RFC 6092, not BCP 38, and if they’re set to non-transparent mode, which is often the default, and sometimes required by law, then routing will still fail.

Hence, it seems to me that BCP 38 and RFC 6092 are both relevant to the draft, and RFC 7084 recommends both of them. Some additional informative references to them seem like they would be helpful here.

—james