Subject: I-D.ietf-v6ops-cpe-simple-security-09

From: james woodyatt <[email-masked]>
Date: Wed, 3 Mar 2010 15:06:19 -0800

everyone--

Once again, I'd like to ask for some discussion and feedback on this draft.  Is there any reason this revision of the draft should not proceed to Working Group Last Call at this time?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Mark Baugher <[email-masked]>
Date: Thu, 4 Mar 2010 15:25:49 -0800

I think this is an important document that seems to be ready to be published.  I have a couple of concerns:

1. Rec-2.  Why not site-scope?

2. Rec-42.  Pardon me if I'm being dense, but what are you saying here?  That service providers cannot manage the device from an exterior interface?

There are many SHOULDs and some should be MUSTs.  I have a long list of nits and such.  I'll send the markups directly to you, James.  Is this Last Call or is this going into Last Call soon?

Mark

---

From: james woodyatt <[email-masked]>
Date: Thu, 4 Mar 2010 15:36:51 -0800

> 1. Rec-2.  Why not site-scope?

Because the subscriber and the provider are not the same organization, and we recommend that CPE routers enforce the organization-local scope boundary to protect subscriber's interior multicast routing up to the organization-local scope level, not just the site-local scope level.  This permits a subscriber to, for example, divide their interior network into multiple site-local multicast routing domains, each with potentially multiple links.

> 2. Rec-42.  Pardon me if I'm being dense, but what are you saying here?  That service providers cannot manage the device from an exterior interface?

No.  Only that the DEFAULT configuration of subscriber managed gateways is that service providers aren't offered a management interface.  If subscribers are issued provider managed gateways, or they explicitly change the DEFAULT configuration of their subscriber managed gateways, then service providers can manage them.

> There are many SHOULDs and some should be MUSTs.  I have a long list of nits and such.  I'll send the markups directly to you, James.  Is this Last Call or is this going into Last Call soon?

The chairs have not made a Last Call.  I'm trying to surface objections before I ask the chairs to issue a Last Call on Sunday evening.

---

From: Fred Baker <[email-masked]>
Date: Thu, 4 Mar 2010 15:46:31 -0800

I'd be willing to do a last call. There was no discussion in Hiroshima, and the discussion in Stockholm left you muttering under your breath. Are you *ready* for a last call?

I would suggest that we have a f2f discussion in Anaheim and decide this then.

> The chairs have not made a Last Call.  I'm trying to surface objections before I ask the chairs to issue a Last Call on Sunday evening.

http://www.ipinc.net/IPv4.GIF

---

From: Fred Baker <[email-masked]>
Date: Thu, 4 Mar 2010 15:56:17 -0800

> 1. Rec-2.  Why not site-scope?

   REC-2: Packets which bear in their outer IPv6 headers multicast
   destination addresses of equal or narrower scope (see section 2.7 of
   IP Version 6 Addressing Architecture [RFC4291]) than the configured
   scope boundary level of the gateway MUST NOT be forwarded in any
   direction.  The DEFAULT scope boundary level SHOULD be organization-
   local scope, and it SHOULD be configurable by the network
   admininistrator.

I'm not even sure I understand the recommendation. To be sure, RFC 4291 knows nothing of an "organization-local" scope; what is likely meant here is "site-local". I'm also not sure I understand the reasoning behind it; I would understand if it said to drop datagrams addressed to wider scopes ("all customers of a given ISP") or narrower scopes (if you mean a specific subnet, which one is that?) but I don't understand why you would drop the datagram if the scope of its address were exactly as configured on the firewall.

> 2. Rec-42.  Pardon me if I'm being dense, but what are you saying here?  That service providers cannot manage the device from an exterior interface?

I should hope they couldn't without the network administration actively doing something to permit them to. As we have discussed privately, a protocol that enables an entity outside my administrative domain to control equipment witin my administrative domain without my explicit authorization is a security issue.

> There are many SHOULDs and some should be MUSTs.  I have a long list of nits and such.  I'll send the markups directly to you, James.  Is this Last Call or is this going into Last Call soon?

Last call will not happen before IETF 77.

---

From: james woodyatt <[email-masked]>
Date: Thu, 4 Mar 2010 16:41:14 -0800

On Mar 4, 2010, at 15:56, Fred Baker wrote:
> 
> I'm not even sure I understand the recommendation. To be sure, RFC 4291 knows nothing of an "organization-local" scope; what is likely meant here is "site-local".

Page 13 of RFC 4291 assigns the value 8 in the 4-bit scope field to Organization-Local and says this about it in the third-to-the-last paragraph:

	Organization-Local scope is intended to span multiple sites
        belonging to a single organization."

I don't really have a strong opinion on site-local vs. organization-local.  I think it says what it currently does because that's what I wrote in the first draft, and it hasn't been much of an issue until now.

I will say that it doesn't make sense to me that my service provider should be allowed to join my organization-local scope multicast groups, or that I can join their organization-local scope groups.  That's what it would mean if we said 'site-local' here instead of what it currently says.

Do we want to recommend that subscriber networks and provider networks be included in the same organization-local multicast scope by DEFAULT?  What would be the theory behind that decision?

> Last call will not happen before IETF 77.

Okay.  I can live with that.

> Are you *ready* for a last call?

Given that this is the first time I've served as a technical editor on a working group draft, I'm not sure I can answer that with any confidence.  I'll defer to the chairs.

> I would suggest that we have a f2f discussion in Anaheim and decide this then.

Sure.  I'll be in Anaheim.

---

From: Mark Baugher <[email-masked]>
Date: Thu, 4 Mar 2010 16:50:19 -0800

> I will say that it doesn't make sense to me that my service provider should be allowed to join my organization-local scope multicast groups, or that I can join their organization-local scope groups…

Site scope give us the same thing and I recommend that we use that instead.

Mark

---

From: james woodyatt <[email-masked]>
Date: Thu, 4 Mar 2010 17:08:51 -0800

> Site scope give us the same thing and I recommend that we use that instead.

I'm confused.  To what "same thing" are you referring?

I've explained that making site-local the DEFAULT multicast scope boundary places the subscriber network in the same organization-local scope as the provider network, whereas making organization-local the DEFAULT multicast scope boundary places the subscriber network and the provider network in different organization-local scopes.

In what way are subscribers and providers part of the same organization?  Why are they not separate organizations by DEFAULT?

---

From: Mark Baugher <[email-masked]>
Date: Thu, 4 Mar 2010 19:03:19 -0800

> I've explained that making site-local the DEFAULT multicast scope boundary places the subscriber network in the same organization-local scope as the provider network, whereas making organization-lo…

You stated it but didn't explain it.  As Fred Baker has pointed out to you in his recent email: 'RFC 4291 knows nothing of an "organization-local" scope'.  I don't see read any explanation in your latest version but only a reference to RFC 4291.  Here are the 4291 definitions:
'Site-Local scope is intended to span a single site. Organization-Local scope is intended to span multiple sites belonging to a single organization.'

> In what way are subscribers and providers part of the same organization?  Why are they not separate organizations by DEFAULT?

Site-local scope means that the multicast messages will not be forwarded outside the site.  That's "the same thing" as what we need.  What about this problem of having my organizational scope multicast visible to my service provider.  Where is it written that a site must be part of a the nearest organization?  My home network is not part of any organization.  If I had organization-scope multicast on my home network, I would not expect my default CPE gateway to forward organization-local messages out my service access-network interface - and vice versa.  Where is your use case of organization-local scope defined?  Not in the source you cite. 

Mark

---

From: Mark Baugher <[email-masked]>
Date: Thu, 4 Mar 2010 19:05:12 -0800

> I should hope they couldn't without the network administration actively doing something to permit them to. As we have discussed privately, a protocol that enables an entity outside my administrativ…

That's right.  And the sentence is clear as it is written.  I misread it.

Mark

---

From: Ole Troan <[email-masked]>
Date: Fri, 5 Mar 2010 10:03:27 +0100

> Site-local scope means that the multicast messages will not be forwarded outside the site.  That's "the same thing" as what we need.  What about this problem of having my organizational scope multi…

if you also want the CPE to be a boundary router for the organizational scope, then aren't you in agreement with James?

see RFC4007. a zone of lesser scope is fully contained within a zone of larger scope. so a organizational-scope boundary will also be a site-local boundary.

cheers,
Ole

---

From: Mark Baugher <[email-masked]>
Date: Fri, 5 Mar 2010 06:26:15 -0800

While I don't think it is necessarily true that 'making site-local the DEFAULT multicast scope boundary places the subscriber network in the same organization-local scope as the provider network', I think its true that both site-local and organization-local need to stay on the 'interior' network.  So it would be better to say what is allowed to be forwarded to and from the exterior (i.e. global-scope multicast) and by implication, everything else is not (organization/site/link-local).

Mark

---

From: Mark Baugher <[email-masked]>
Date: Fri, 5 Mar 2010 06:37:25 -0800

> see RFC4007. a zone of lesser scope is fully contained within a zone of larger scope. so a organizational-scope boundary will also be a site-local boundary.

Yes, that thought struck me this morning.  RFC 4007 should be cited in the I-D, that should be enough.

Mark

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Fri, 5 Mar 2010 10:26:55 -0500

> While I don't think it is necessarily true that 'making site-local the
> DEFAULT multicast scope boundary places the subscriber network in the
> same organization-local scope as the provider network', I think its
> true that both site-local and organization-local need to stay on the
> 'interior' network.  So it would be better to say what is allowed to
be
> forwarded to and from the exterior (i.e. global-scope multicast) and
by
> implication, everything else is not (organization/site/link-local).

I think it's important to say something, so there is some expectation of
consistency in the default behavior. For the average consumer, I think
that organizational scope is reasonable.

In general, I think this draft is in good shape, and I'd like to see it
progress.
Barbara

---

From: james woodyatt <[email-masked]>
Date: Fri, 5 Mar 2010 10:51:09 -0800

> Yes, that thought struck me this morning.  RFC 4007 should be cited in the I-D, that should be enough.

I've added that to my To-Do list for a forthcoming -10 revision.  I'd like to invite further discussion on the draft today, and I'll be in and out of the list all weekend.

---

From: Rémi Després <[email-masked]>
Date: Mon, 8 Mar 2010 18:19:50 +0100

Retransmission to the list (omitted by mistake).

Début du message réexpédié :

> De : Rémi Després <[email-masked]>
> Date : 8 mars 2010 09:22:38 HNEC
> À : james woodyatt <[email-masked]>
> Cc : Brian E Carpenter <[email-masked]>
> Objet : Rép : I-D.ietf-v6ops-cpe-simple-security-09 - ICMP Error Messages
> 
> James,
> 
> Sorry to come so late on this tread.
> But the point below is IMHO important.
> 
> In the draft, the only REC-n concerning ICMP is so far:
> "REC-16: If a gateway forwards a UDP exchange, it MUST also forward ICMP Destination Unreachable messages containing UDP headers that match the exchange state record."
> 
> In my understanding, what is needed is, for each of the transport protocols:
> "REC-n: If a gateway forwards a NNN exchange, it MUST also forward, in both directions, ICMP Error messages containing UDP headers that match the exchange state record."
> 
> - Forwarded error messages must be also for TCP, DCCP, etc., and must be more general than just Destination Unreachable: they must include in particular Packet Too Big notifications which are essential for IPv6 path-MTU discovery.
> - Reliable PMTUD is much more important in IPv6 than in IPv4.
> While IPv4 packets can be fragmented within the network where they are too long for the local MTU, IPv6 fragmentation is only end to end. 
> Thus, as long as PMTUD cannot be considered reliable, all IPv6 MTUs must remain clamped to 1280 octets. 
> This is not really dramatic, but is significantly less than optimum in many environments. Furthermore, in dual-stack hosts that apply the same MTU to IPv4 and IPv6, and also to on-link and off-link packets, this limitation spreads out to on-link IPv4 packets, which is also less dramatic than losing connectivity, but is unfortunate.
> 
> I have added Brian as destination because of the point he made, in Softwire, that in IPv6-PMTUD was unreliable.
> 
> Regards,
> 
> RD
> 
> 
> 
>> everyone--
>>

---

From: james woodyatt <[email-masked]>
Date: Thu, 11 Mar 2010 12:17:25 -0800

> "REC-n: If a gateway forwards a NNN exchange, it MUST also forward, in both directions, ICMP Error messages containing UDP headers that match the exchange state record."

Please also see REC-29, REC-34 and REC-38.

> - Forwarded error messages must be also for TCP, DCCP, etc., and must be more general than just Destination Unreachable: they must include in particular Packet Too Big notifications which are essen…

Agreed, but I'm now inclined to remove all four of those recommendations and insert an explicit recommendation into the "Stateless Filters" section that cites RFC 4890 and specifically references section 4.3.1 "Traffic The Must Not Be Dropped".

Does anyone object to that revision?

---

From: Rémi Després <[email-masked]>
Date: Fri, 12 Mar 2010 14:05:13 +0100

1.
Le 11 mars 2010 à 21:17, james woodyatt a écrit :
> ...
>> - Forwarded error messages ... must be more general than just Destination Unreachable: they must include in particular Packet Too Big notifications which are essential for IPv6 path-MTU discovery.
> 

No objection, and active support for this approach.
(You are right, ICMP is at the IP layer, not at the transport layer.)

2.
The draft uses "interior" and "exterior", while the traditional vocabulary for NATs is AFAIK "internal" and "external" (e.g. in RFC 4787).
A suggestion would be to align the vocabulary. 

RD

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Mar 2010 19:00:47 +0100

I would like to propose some form of "ParanoidOpeness" (Rule #7) from 
draft-vyncke-advanced-ipv6-security-01 to be brought into the 
simple-security draft.

The basic idea is that rather than blocking otherwise unauthorized 
inbound connections outright, the CPE rate-limits them according to a 
variable setting. When that setting is 0, all incoming packets are 
dropped. When set to its maximum, all packets are permitted (as if the 
firewall function is configured off). In-between, the CPE rate-limits 
incoming packets to reduce probing of the home network, but to allow 
just enough packets through that, if a host inside responds, a pinhole 
is opened for the communication to occur. Of course, the hard part is 
what the default setting should be, but I'd like to get a sense first of 
whether we can bring this function in.

James, I think I remember you being warm to the idea in some (jabber?) 
comments during the meeting in Hiroshima when I presented this first.

Thanks,

- Mark

On 3/4/10 12:06 AM, james woodyatt wrote:
> james woodyatt<[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Mar 2010 08:34:11 +1300

Mark, I'm not going to reply to your specific question.

The one most clear result from the ISP survey I will report
on during the IETF is that the biggest gap in products holding
up general v6 deployment is CPE.

I think it's a matter of great urgency to get this draft
out as an RFC; it's a couple of years too late.

So I want to say: let's not add *anything*. Let's just
push it out in a matter of weeks.

The same applies to draft-ietf-v6ops-ipv6-cpe-router
of course.

Regards
   Brian Carpenter

On 2010-03-20 07:00, Mark Townsley wrote:
>> Once again, I'd like to ask for some discussion and feedback on this
>> draft.  Is there any reason this revision of the draft should not
>> proceed to Working Group Last Call at this time?
>>
>>
>> --

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Mar 2010 21:12:26 +0100

> Mark, I'm not going to reply to your specific question.
That's too bad.
> up general v6 deployment is CPE.
Understood.
> out as an RFC; it's a couple of years too late.
It's more the implementations that are late, but I get your point.
> push it out in a matter of weeks.

All we are doing is talking about allowing what is now a binary on/off 
in the draft now to be a variable between 0 and some maximum instead. 
The default could still well be what we have now, 0, though I would like 
it to be something else.

I'm not sure that leaving this out will help advance the draft more 
quickly. Folks like me, who are quite happy with their native IPv6 
service for the past couple of years with no IPv6 firewall, think of 
cpe-simple-security as a sword in the heart of IPv6 and end-to-end 
transparency. Including "Rule 7" is something that would go a long way 
towards at least me stepping back and not making an enormous ruckus when 
this draft hits last call.

We've already talked about the idea in v6ops, it's been documented in a 
draft for at least a little while, and after Hiroshima I got some 
indication that this was something people would like to have. The basic 
concept comes from Dave Oran, who included it in various presentations 
for years.

So, aside of your fears of changing anything in the draft at all, what 
do you think of the idea?

- Mark

---

From: james woodyatt <[email-masked]>
Date: Fri, 19 Mar 2010 15:09:28 -0700

On Mar 19, 2010, at 12:34, Brian E Carpenter wrote:
> 
> So I want to say: let's not add *anything*. Let's just push it out in a matter of weeks.

I'm currently sitting on a couple of minor edits:

+ Cite RFC 4007 to clear up confusion about multicast group scope boundaries.
+ Fix some inconsistencies between cpe-simple-security and RFC 4890.

I'm planning to post the -10 revision tonight, then start revising my slides for Monday morning.  We shall see if there is a rough consensus for sending the -10 revision up the stack in the days following the meeting, or if further wrangling over it in the working group is in order.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 20 Mar 2010 12:50:41 +1300

Mark,

I dislike 'default deny' as much as anyone. After all,
I'm an author of RFC 4864.

But I'm afraid that the simplicity of 'default deny' has long
ago won the hearts and minds of enterprise network managers.
I can see the virtues of rate limiting, but I see it as too
contentious to attempt to get it into the *simple* security
draft. Sadly.

Regards
   Brian

---

From: james woodyatt <[email-masked]>
Date: Fri, 19 Mar 2010 17:32:21 -0700

> ago won the hearts and minds of enterprise network managers.

Sadly, enterprise network managers aren't the only people whose legitimate interests are at stake in the matter under discussion.

---

From: Mark Townsley <[email-masked]>
Date: Sat, 20 Mar 2010 08:04:17 +0100

> ago won the hearts and minds of enterprise network managers.
The Enterprise edge is very different than the Residential edge. This 
draft is targeting the Residential edge.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sat, 20 Mar 2010 20:32:56 +0100

> Sadly, enterprise network managers aren't the only people whose legitimate interests are at stake in the matter under discussion.
This document is clearly scoped in the first sentence of the Introduction to:

"gateway devices that enable delivery of Internet services in residential and small office settings."

So, I'm not sure why we are even considering enterprise network managers here.

The networks themselves, the assets under protection, the types of applications, are quite different
between and enterprise network and residential network.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sat, 20 Mar 2010 20:40:24 +0100

> I'm planning to post the -10 revision tonight, then start revising my slides for Monday morning.  We shall see if there is a rough consensus for sending the -10 revision up the stack in the days fo…
Wish I could be at the meeting next week to make my points there, but if 
I was I would be asking for something along the lines of this:

Section 2.3, first paragraph:

s/not forwarded into the/rate-limited or discarded before reaching the

And a new sentence like this:

Rate-limiting unsolicited inbound connections rather than rejecting them 
provides greater end-to-end transparency while still providing 
protection against address and port scanning attacks as well as 
overloading of slow links or devices within the home.

Thanks,

- Mark

PS. I have some other clarification suggestions and questions to ask 
about text I read while reviewing today. I'll wait for -10 before 
posting these.

---

From: Fred Baker <[email-masked]>
Date: Sat, 20 Mar 2010 12:54:11 -0700

I use such a device in my home as part of an enterprise network...

---

From: Fred Baker <[email-masked]>
Date: Sat, 20 Mar 2010 12:53:36 -0700

On Mar 20, 2010, at 12:40 PM, Mark Townsley wrote:

> Rate-limiting unsolicited inbound connections rather than rejecting them provides greater end-to-end transparency while still providing protection against address and port scanning attacks as well as overloading of slow links or devices within the home.

SIlly question. Why do you believe that? An address or port scanning attack is not intended to overload a network, it is intended to find an address port that can be used or attacked. Making the scan take more time doesn't prevent it from reaching its target. In what way does rate limiting an address or port scan provide protection?

---

From: Mark Townsley <[email-masked]>
Date: Sat, 20 Mar 2010 23:38:27 +0100

> I use such a device in my home as part of an enterprise network...
The point is that the document is clearly scoped to residential and 
small office settings.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sat, 20 Mar 2010 23:50:47 +0100

On 3/20/10 8:53 PM, Fred Baker wrote:
> SIlly question. Why do you believe that? An address or port scanning attack is not intended to overload a network, it is intended to find an address port that can be used or attacked.
The sentence is referencing two different things. One, the possibility 
that uninvited packets might overload some device or slow link 
(something I consider unlikely, but has been identified as a concern by 
some), the other is, indeed, designed to make blind port and address 
scanning less likely to succeed in a given amount of time.

- Mark
>   Making the scan take more time doesn't prevent it from reaching its target. In what way does rate limiting an address or port scan provide protection?
>

---

From: Fred Baker <[email-masked]>
Date: Sat, 20 Mar 2010 15:55:52 -0700

> The sentence is referencing two different things. One, the possibility that uninvited packets might overload some device or slow link (something I consider unlikely, but has been identified as a concern by some), the other is, indeed, designed to make blind port and address scanning less likely to succeed in a given amount of time.
> 
> - Mark

With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack take ten minutes vs five. They're asking about preventing an attack from succeeding. Now, we can discuss the logic of the notion that "the bad guys are out there and the good guys are in here", but given the assumption, we need to be rational about the threats we are trying to prevent from succeeding.

---

From: Shane Amante <[email-masked]>
Date: Sat, 20 Mar 2010 17:59:16 -0600

Mark, Fred,

> With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack ta…

Agreed.  This proposal seems like a poor half-measure.  IMHO, if a client/host wants real end-2-end transparency, then it should use something like NAT-PMP to explicitly signal to the upstream FW that the client is wise and mature enough to deploy it's own, onboard FW to protect itself.  Although some people may think that's a bad idea, because a malware-infected PC/device could signal an upstream FW to open up everything, I personally think that's a very poor argument.

Namely, once a PC/device is infected, it's game-over, anyway.  Specifically, remote attackers already have the ability to remotely control that PC and perform further reconnaissance and attacks both /inside/ and outside the LAN.  Second, if technically savvy people still don't like the idea of NAT-PMP operating on their FW, then they will be smart enough to disable it altogether on their (personal) FW's.  

-shane

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 21 Mar 2010 13:19:50 +1300

On 2010-03-21 08:32, Mark Townsley wrote:
>> Sadly, enterprise network managers aren't the only people whose
>> legitimate interests are at stake in the matter under discussion.
>>    

Fair enough, but...
> between and enterprise network and residential network.

Indeed. But ISPs that supply CPE to their customers are going to
assume that their customers are running unpatched insecure operating
systems at high risk of catching malware. So I think they are just as
likely as enterprise IT departments to favour default deny approaches.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Mar 2010 11:30:37 +1030

On Sat, 20 Mar 2010 15:55:52 -0700

> With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack ta…

One thing that does seem to be missing from the draft is a specific
list of threats it is attempting to mitigate i.e. a threat model. With
luck, that sort of list would end up on the outside of the cardboard
box the CPE comes in, so that when people buy the CPE, they don't
assume the device is taking care of "all security", and therefore don't
have to bother with any other security measures.

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Mar 2010 12:21:53 +1030

On Sun, 21 Mar 2010 13:19:50 +1300

> likely as enterprise IT departments to favour default deny approaches.

I can't speak for all ISPs, however the ones I've worked at here in
Australia don't make that assumption universally. There will be a
percentage of customers who have that issue, however they'll be the
minority, and they'll have trouble pretty quickly because of it.

One other broader issue with making that assumption is boundaries of
responsibility / care. If ISPs universally assume that customers devices
are insecure, unmaintained and unpatched, and take active yet
limited measures to mitigate that, some customers might then believe
that the ISP is taking care of all their Internet security needs. If a
customer then suffers a security incident and has a financial loss
because if it, they might try to sue the ISP for the loss because they
believe the ISP is taking care of all their Internet security. 

Regards,
Mark.

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 20 Mar 2010 20:00:03 -0700

> With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack ta…

Agreed, rate-limiting does not add value in this scope.  We know that
IPv6 is hard to scan successfully, and we know that rate limiting it
on the CPE won't protect the external link from becoming saturated
during an attack.  From the service provider perspective, rate
limiting causes inconsistency in services (some packets get through in
this sample test but not in the next sample test) and thus injects
greater complexity for the folks trying to troubleshoot. I prefer
consistent and deterministic behavior.  I would say the principle of
default-deny and least privilege are philosophically correct in
general, but i am not sure it needs to be applied in simple CPE.  I
believe most current host OS software ships these days with default
deny, and authorized administrators and applications can open the
proper ports when needed.  If the trend is default-deny on the host
which is "application aware", we do not need default-deny on the
simple CPE which is not application aware.

Cameron

---

From: james woodyatt <[email-masked]>
Date: Sat, 20 Mar 2010 23:00:40 -0700

On Mar 20, 2010, at 18:00, Mark Smith wrote:
> 
> One thing that does seem to be missing from the draft is a specific list of threats it is attempting to mitigate i.e. a threat model.

RFC 4864 doesn't offer one, and its authors haven't offered much in the way of specifics to the discussion here or on the design team list.  Perhaps, you'd like to offer a contribution?

The Overview contains my best attempt at explaining what considerations I think are really in play behind the CPE Simple Security recommendation.  Here's what I think is the most relevant excerpt:

>> The stateful packet filtering behavior of NAT set user expectations that persist today with residential IPv6 service.  "Local Network Protection for IPv6" [RFC4864] recommends applying stateful packet filtering at residential IPv6 gateways that conforms to the user expectations already in place.

In other words, we recommend filtering at the middlebox-- making IPv6 routers do filtering like IPv4/NAT gateways do-- because "defense in depth" is a virtue in and of itself, and that Internet users have come to expect it.  Apparently, there's a consensus in IETF that this is enough reason to do it, and I strongly suspect that an explicit threat model might be inviting more controversy than anyone wants to endure.

---

From: Mark Smith <[email-masked]>
Date: Sun, 21 Mar 2010 18:38:07 +1030

Hi James,

On Sat, 20 Mar 2010 23:00:40 -0700

> RFC 4864 doesn't offer one, and its authors haven't offered much in the way of specifics to the discussion here or on the design team list.  Perhaps, you'd like to offer a contribution?

While threat model is probably the correct term, more broadly I think
probably something of a problem statement i.e. what security measures
the CPE does provide, and what it doesn't, probably with some
justification.

I think the role of IPv6 CPE in the residential Internet security model
is different to the role IPv4/NAT CPE commonly is or was capable of
playing.

Stating the obvious, IPv4/NAT provides a much harder boundary between
internal and external devices, primarily due to the nature of NAPT.
NAPT by it's nature provides a default deny to inbound traffic. That's
what breaks end-to-end. Because of that harder boundary, I think
end-user expectations are that the IPv4/NAPT CPE can perform much
more of a primary security role when it comes to protecting them from
the Internet.

The nature of the operation of NAPT inherently defined a set of threats
that it protected against. 

With IPv6/CPE security, by trying to restore end-to-end, I think we're
inherently reducing the security that people formerly had with
IPv4/NAPT CPE. End nodes will now have to play more of a primary
security role, with filtering IPv6/CPE providing an
assisting/secondary/defence in depth role.

Now that IPv6 end-nodes will be "burdened" with more security
responsibility, I think it is important to make sure it is clear that
the security functions performed in IPv6 CPE aren't exactly the
same as as they were in IPv4/NAPT CPE. 

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Sun, 21 Mar 2010 14:38:31 +0100

Hi,

> likely as enterprise IT departments to favour default deny approaches.

We're not.

We provide *Internet* services.  Not "walled garden" services.

If the customer wants firewall protection, we're happy to sell it to them,
but the default package they get is "Internet".  Packets transported from
A to B and vice versa, and we're not maing their packets unhappy unless they
tell us so.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  150584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Mark Townsley <[email-masked]>
Date: Sun, 21 Mar 2010 15:05:05 +0100

> With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack ta…
There is nothing irrational about making a hacker's job more difficult. 
That is the basis behind every measure in the document now. None of them 
make it impossible for a system to be compromised, just more difficult.

Virtually all of the firewall functions in this draft are imposing a 
certain kind of limited end to end connectivity for the average user on 
the IPv6 Internet. The tradeoff for this limitation is the promise of 
security. I have little doubt that a determined hacker will be able to 
get around each and every measure identified in the document. At best, 
the bar is simply being raised to make the hacker's job a bit more 
difficult, perhaps reducing the number which are actually successful. 
The argument we are having is over how high to raise the bar, and at 
what cost in terms of transparency. I'd like us to have to possibility 
of keeping it just a slight bit lower for IPv6 than what we have for 
IPv4. I don't see why we should set the bar at the same level until 
there is evidence that the machines running IPv6 (Windows Vista, 7, 
MACOSX - each which are shipped with update programs and embedded IPv6 
personal firewalls) are as vulnerable as the whole gamut of IPv4 systems 
available today.

"Unsolicited" incoming connections are a huge benefit for application 
simplicity. In various consumer surveys, remote access to devices in the 
home is listed as one of the most important features that residential 
subscribers would like to see more of. The various firewall control 
protocols are far from being completed and add their own complexity - 
complexity that in a real threat analysis might show just as many 
security issues as just leaving the door open a crack. And, that's what 
I am advocating here. A knob that allows the door to be open, shut, or 
something in-between.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sun, 21 Mar 2010 15:22:01 +0100

> Agreed.  This proposal seems like a poor half-measure.  IMHO, if a client/host wants real end-2-end transparency, then it should use something like NAT-PMP to explicitly signal to the upstream FW t…
If you take most of these types of arguments to their logical end, I 
think you'll find that the only real defense here is keeping the 
end-devices secure. Particularly those that travel outside of the home 
and can be infected while away, etc. Given that there is little or no 
real data on whether IPv6 residential firewalls actually fend off 
hackers, we are responding to a lot of hypothetical analysis and 
conjecture. Much of it is to, in the end, make the user, ISP, or 
whomever is responsible "feel" more secure (insert analogies of airport 
security pat-downs here).

So, we're probably not going to get very far on technical arguments. 
What the rate-limiting does is ensure that "only a few per second" 
packets get on the inside. If you are a valid application trying to make 
a connection to a valid open port known in advance, then this is all you 
need. If you are a hacker without that information, you probably need to 
try a few more times.

This, importantly for whether someone "feels" safe, is to give a setting 
somewhere between "wide open" and "completely closed". I'd say a lot of 
users fall in that category.
> Namely, once a PC/device is infected, it's game-over, anyway.
And the attack vectors are often above L4 these days.
>    Specifically, remote attackers already have the ability to remotely control that PC and perform further reconnaissance and attacks both /inside/ and outside the LAN.  Second, if technically savvy people still don't like the idea of NAT-PMP operating on their FW, then they will be smart enough to disable it altogether on their (personal) FW's.
>    
I wish I could conjure up confidence that a single, interoperable, 
secure, ubiquitously available, FW control protocol will exist for IPv6. 
Given that we haven't been able to achieve that for IPv4, I find it hard 
to believe we will for IPv6. Assuming it will happen is little more than 
wishful thinking at this stage.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Mar 2010 06:29:01 +1300

> A to B and vice versa, and we're not maing their packets unhappy unless they

I applaud that and it's what I want from my ISP. My comment is that
I don't see this as a universal approach.

So, I'm wondering what's really wrong with:

  REC-41  Gateways MUST provide an easily selected configuration option
      that permits operation in a mode that forwards all unsolicited
      flows regardless of forwarding direction.

 - Brian

---

From: Mark Townsley <[email-masked]>
Date: Sun, 21 Mar 2010 19:39:33 +0100

On 3/21/10 4:00 AM, Cameron Byrne wrote:
> On Sat, Mar 20, 2010 at 3:55 PM, Fred Baker<[email-masked]>  wrote:
>    
I agree with you, Cameron. The idea of rate-limiting is a compromise 
between this opinion and what is in the draft now. I'd be more than 
happy with what you propose here.

- Mark

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Mar 2010 05:36:25 +1030

On Mon, 22 Mar 2010 06:29:01 +1300

>       flows regardless of forwarding direction.

I don't see anything wrong with it. That the "Vanilla Router"
checkbox. In some respects is equivalent to bridge mode on ADSL
routers today, which allow end-hosts to terminate the PPPoE/PPP
sessions, rather than have the upstream ADSL router do it.

Regards,
Mark.

---

From: Mark Townsley <[email-masked]>
Date: Sun, 21 Mar 2010 20:18:05 +0100

>        flows regardless of forwarding direction.
The problem is the default, which is not to permit this.

- Mark

---

From: james woodyatt <[email-masked]>
Date: Sun, 21 Mar 2010 13:29:50 -0700

> The problem is the default, which is not to permit this.

That problem is inherited from RFC 4864, which this draft is not  
intended to reverse.

-jhw

Sent from my phone

---

From: Mark Townsley <[email-masked]>
Date: Sun, 21 Mar 2010 22:12:46 +0100

> In other words, we recommend filtering at the middlebox-- making IPv6 routers do filtering like IPv4/NAT gateways do-- because "defense in depth" is a virtue in and of itself, and that Internet use…
So, you are saying there is IETF consensus on a security solution for 
IPv6 based largely on the status quo of IPv4, but no consensus on what 
security problem either are actually solving. If we are shooting for 
status quo and similar user experience, we should go ahead and include 
NAT. At least then the user gets stable independent addressing, 
regardless of what the ISP offers.

Imagine Los Angeles manages to get everyone to move to electric cars, 
but the local populace decides that they liked the smog that blocked the 
sun, the daily pollution indicators, etc. and decides to pump smoke into 
the atmosphere to ensure that the user expectation of the inhabitants 
remains unchanged.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sun, 21 Mar 2010 22:25:29 +0100

On 3/21/10 9:08 AM, Mark Smith wrote:
> james woodyatt<[email-masked]>  wrote:
>
>    
Which that vast majority of IPv6-enabled devices already do.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sun, 21 Mar 2010 22:28:01 +0100

> That problem is inherited from RFC 4864, which this draft is not 
Why not, if that is the current consensus? We've reversed the text of 
IETF standards track documents before, much less Informational documents 
that are not a standard of any kind.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 22 Mar 2010 11:14:21 +1300

> that are not a standard of any kind.

As a co-author of 4864, let me agree violently. It's not a BCP.
Even if it was, consensus could reverse it.

What 4864 says is: NATs weren't designed as security devices but they
provide simple security by blocking everything incoming by default.
To implement simple security for v6 you should do it with a stateful
firewall.

It doesn't say that CPEs MUST do this. It leaves that choice open, as
an informational document.

    Brian

---

From: james woodyatt <[email-masked]>
Date: Sun, 21 Mar 2010 22:19:21 -0700

>> that are not a standard of any kind.

The design team was directed by the chair to write a draft that detailed the recommendation in Section 4.2 of RFC 4864 for a stateful filter in residential IPv6 CPE routers, and we were not instructed that revisiting the recommendation with an eye toward reversing it was explicitly within our ambit.

> To implement simple security for v6 you should do it with a stateful

I would have expected an author of RFC 4864 to quote the following excerpt from Section 4.2 instead:

   To implement simple security for IPv6 in, for example, a DSL or cable
   modem-connected home network, the broadband gateway/router should be
   equipped with stateful firewall capabilities.  These should provide a
   default configuration where incoming traffic is limited to return
   traffic resulting from outgoing packets (sometimes known as
   reflective session state).  There should also be an easy interface
   that allows users to create inbound 'pinholes' for specific purposes
   such as online gaming.

That paragraph is the whole reason that I-D.ietf-v6ops-cpe-simple-security exists today.  Note the use of the word "should" in the verb phrase of the second sentence.  It sure looks to me like it makes a value judgment that IPv6 Simple Security in unmanaged home routers is considered helpful.

When I first read Section 4.2 of the Internet Draft that would become RFC 4864, just a little over three years ago, I sent <http://ops.ietf.org/lists/v6ops/v6ops.2007/msg00055.html> to the V6OPS list to surface what I thought, at the time, was an oversight.  Note that I was objecting to the use of the word "should" in that paragraph.  I thought RFC 4864 should not be making such a recommendation, and I believed that the authors must have been mistaken to include it in an Informational category document.

Alas, I later learned that this recommendation was quite deliberate and *NOT* open for discussion anymore.  I withdrew my objection soon thereafter, after one of the authors expressed "violent" disagreement with me, because I came to believe my personal misgivings about this recommendation weren't shared by the majority of IETF participants.  I still think only a small minority of participants agrees with me.

> It doesn't say that CPEs MUST do this. It leaves that choice open, as an informational document.

No, it doesn't say that CPE routers MUST do this, but it does go out of its way to say that CPE routers "should" do this.

More importantly, other specifications which reference RFC 4864 as if it's morally equivalent to a proposed standard *do* say that CPE routers MUST do this.  While categorized as Informational, the language in I-D.ietf-v6ops-cpe-simple-security is deliberately crafted to be easily cited by other SDO's in requirement specifications, which are expecting to describe not just the CPE routers MUST do this, but HOW they will do this.  I am aware of at least two other SDO's that are preparing exactly that.

So, while it's true that neither RFC 4864 nor I-D.ietf-v6ops-cpe-simple-security say that CPE routers MUST implement a "default deny" stateful filtering regime, the common law is congealing around this as a requirement as we speak.  So, despite the fact that this draft is Informational and not BCP or Proposed Standard, what we say in this document should it be published in the RFC series is very likely to become the Law of the Internet pretty much overnight, and I think that pretending otherwise would be awfully naïve.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 22 Mar 2010 08:43:53 +0100

This exchange highlights a very significant point with respect to the 
content in v6ops-cpe-simple-security.

According to its author, v6ops-cpe-simple-security has been operating 
under the influence of precedent from RFC 4864, something that was never 
intended by the authors of the RFC, nor something expected under IETF 
procedures.

- Mark

On 3/21/10 11:14 PM, Brian E Carpenter wrote:
>>> On Mar 21, 2010, at 12:18, Mark Townsley<[email-masked]>  wrote:
>>>

---

From: Mark Townsley <[email-masked]>
Date: Mon, 22 Mar 2010 08:58:06 +0100

> To implement simple security for v6 you should do it with a stateful
Right, NAPTs were invented primarily for address amplification, but also 
brought simple security and address independence.

Address amplification is something that IPv6 currently does not need, 
and address independence is something that would be quite useful but we 
haven't been able to design and deploy it without breaking end-to-end.

The firewall function in simple-security explicitly damages end-to-end. 
If we go this route, we might as well toss in NAT too as we will have 
already paid the price in terms of end-to-end transparency; We might as 
well get the address independence benefit along with it.

I suspect this will be used as an argument in the future if stateful 
firewall operations become ubiquitous in CPEs: How is NAT *that much* 
worse than the firewall you already have?

- Mark

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Mar 2010 19:21:44 +1030

On Mon, 22 Mar 2010 08:58:06 +0100

> brought simple security and address independence.

I agree. The security (I'd like to put that in quotes, but there is a
fair bit of it) of NAPT wasn't by design, but as a consequence of 
the nature of it's operation. It is default deny because it is
impossible for it not to be.

RFC4864, despite it's more politically correct name (can't remember
the earlier more accurate, albeit controversial one), is about exactly
replicating the security functions of IPv4 NAT that people have come to
expect, using IPv6 methods - because they couldn't "expect" anything
else. From the Abstract:

"  Although there are many perceived benefits to Network Address
   Translation (NAT), its primary benefit of "amplifying" available
   address space is not needed in IPv6.  In addition to NAT's many
   serious disadvantages, there is a perception that other benefits
   exist, such as a variety of management and security attributes that
   could be useful for an Internet Protocol site.  IPv6 was designed
   with the intention of making NAT unnecessary, and this document shows
   how Local Network Protection (LNP) using IPv6 can provide the same or
   more benefits without the need for address translation."

IOW, if you really want to exactly replicate IPv4/NAT type security in
IPv6, this is how you do it.

I think the CPE draft, OTOH, should be saying "this is how you should be
doing security in IPv6". I think restoring end-to-end, at least
partially or configurably fully, is a key requirement. I think the CPE
draft already does that. Arguably, that also already makes it inferior
to IPv4/NAPT, because end-nodes will be directly visible over the
Internet. However, we also know that end-nodes are much more security
aware and capable than they used to be, so we're able to loosen CPE
security to help restore end-to-end because we know that modern
end-nodes are going to take up the slack. The CPE becomes a security
assistant, not a security authority.

This is why I've thought a bit more definite problem statement would
help. If it is purely to replicate IPv4/NAPT CPE functionality in IPv6,
then either RFC4864 would already do, or possibly a slightly more CPE
oriented version needs to be produced. If, however, it is to state
"this is how IPv6 CPE security should be done", then I think we should
leave legacy IPv4/NAPT concepts that aren't appropriate behind.

Regards,
Mark S.

---

From: Mark Townsley <[email-masked]>
Date: Mon, 22 Mar 2010 11:17:47 +0100

James, if anyone who suggested to you that RFC 4864 or any Informational 
document represented the consensus of the IETF, you were sadly misled. 
However, if it is true what you say that, "this document should it be 
published in the RFC series is very likely to become the Law of the 
Internet pretty much overnight" then we better be sure we have consensus 
on what it says.

I do not want to see the IETF recommending a default-deny rule on IPv6 
residential gateways, and I regret that RFC 4864 has been interpreted as 
recommending this with any authority in the past. I've offered one 
admittedly imperfect compromise, but I find it better than wishing for a 
pin-hole protocol that doesn't exist and may never in a ubiquitous and 
interoperable manner. Even if such a protocol did exist, there are very 
legitimate security concerns about the effectiveness of operating what 
is essentially a distributed IP-stack between the host and RG vs. using 
a local firewall on the host. These have been brought up, but not fully 
discussed in this document or on the list.

Bottom line: I think that the IETF should not publish any documents 
implying a default-deny rule as a recommended practice and default 
setting for IPv6 residential gateways. I think it is fine to describe 
how this should work should it be turned on, and that a configuration 
knob MUST exist, but the default should be set in a way that ensures it 
is "beneficial" and "not harmful to the Internet as a whole" (RFC 3935, 
BCP 95).

The market always makes the final decision, and if it decides that 
customers want, or vendors want to sell, equipment with a default 
setting that breaks end-to-end transparency, there is no stopping this 
from happening. But, the IETF doesn't have to help it happen. I think 
the simple-security document, as a whole, doesn't risk being ignored if 
it leans a bit toward favoring IPv6 end-to-end transparency vs. IPv4 
status quo in this one case.

- Mark

On 3/22/10 6:19 AM, james woodyatt wrote:
> When I first read Section 4.2 of the Internet Draft that would become RFC 4864, just a little over three years ago, I sent<http://ops.ietf.org/lists/v6ops/v6ops.2007/msg00055.html>  to the V6OPS list to surface what I thought, at the time, was an oversight.  Note that I was objecting to the use of the word "should" in that paragraph.  I thought RFC 4864 should not be making such a recommendation, and I believed that the authors must have been mistaken to include it in an Informational category document.
>

---

From: Ole Troan <[email-masked]>
Date: Mon, 22 Mar 2010 06:07:55 -0700

[...]

> More importantly, other specifications which reference RFC 4864 as if it's morally equivalent to a proposed standard *do* say that CPE routers MUST do this.  While categorized as Informational, the…

which SDO's are you thinking of?
TR-124i2 references the simple security draft but does not make any recommendation that the functionality must be enabled by default. same for the basic IPv6 CE router draft.

cheers,
Ole

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Mar 2010 03:28:48 +1300

I don't think we should really be doing textual analysis
of an informational document, but since you quoted it:

On 2010-03-22 18:19, james woodyatt wrote:
...
>    that allows users to create inbound 'pinholes' for specific purposes

Correct, and (given what was already quoted from the abstract) I have always
read that paragraph to start implicitly with the words

"If you want to... "

and understood "simple security" to refer to the preceding text that
describes NATs as providing "simple security" via default deny.
And that was because we believed that many network managers wanted
exactly that and believed that NAT66 was the way to achieve it.
So we wanted to document how to achieve the same effect without NAT.
Obviously, if you don't want that effect, don't implement
draft-ietf-v6ops-cpe-simple-security, or use its REC-41 option.

       Brian