Subject: draft-ietf-v6ops-cpe-simple-security-00

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 4 Dec 2007 12:36:06 -0800

Looking at draft-ietf-v6ops-cpe-simple-security-00:

"The operational goals of security capabilities in Internet gateways  
are described with more detail in "Local Network Protection for  
IPv6" [IPv6-NAP], but they can be summarized as follows.

o Check all traffic to and from the public Internet for basic sanity,  
e.g. anti-spoofing and "martian" filters.
o Allow tracking of application usage by source and destination  
transport addresses.
o Provide a barrier against untrusted external influences on the  
interior network by requiring filter state to be activated by traffic  
originating at interior network nodes.
o Allow manually configured exceptions to the stateful filtering rules  
according to network administration policy."

The first bullet is fairly obvious (although personally I've never  
felt the need to filter packets that are going to fail just fine on  
their own) but I'm not quite sure what the other bullets get at...

Some things that may deserve attention in the draft:

What about packets with unknown next headers?

On the one end you don't want bad guys to work around filters by  
inserting a header or two between the IPv4 and TCP or UDP headers, but  
on the other hand you don't want to make innovation impossible by  
filtering out anything that didn't exist when the CPE was shipped.

An extra complication is that although there is a fairly standard  
extension header format, not all headers conform to this format, so it  
may or may not be possible to look beyond an unknown header in a packet.

PMTUD is mentioned but no language about allowing the required packet  
too big messages through. This is extremely important, PMTUD black  
holes are a big problem, and some of the IPv4 worarounds aren't  
available in IPv6. It may even be useful to allow the CPE to advertise  
a reduced MTU on the LAN side to work around upstream PMTUD breakage,  
although it wouldn't be a good idea to enable this by default, IMO.

Some other stuff that routinely cause trouble with at least some  
firewalls: diffserv bits in the IP header, ECN, TCP options in general  
and window scale in particular. Do we need to say anything about  
these? (Some firewalls ignore the window scale option but then block  
"out of window" segments.)

---

From: james woodyatt <[email-masked]>
Date: Tue, 4 Dec 2007 15:56:14 -0800

On Dec 4, 2007, at 12:36, Iljitsch van Beijnum wrote:
>
> o Check all traffic to and from the public Internet for basic  
> sanity, e.g. anti-spoofing and "martian" filters.
> interior network by requiring filter state to be activated by  
> traffic originating at interior network nodes.
> o Allow manually configured exceptions to the stateful filtering  
> rules according to network administration policy."
>

I keep hearing the phrase "attack surfaces" every time I try to run  
that argument past my security advisors.

> What about packets with unknown next headers?

Indeed.  What about them?  I would assert that packet filters should  
assume they are last headers and treat them like unknown transport  
layer headers.  Is there another option available?

> inserting a header or two between the IPv4 and TCP or UDP headers,  
> but on the other hand you don't want to make innovation impossible  
> by filtering out anything that didn't exist when the CPE was shipped.

You may not want to interfere with innovation, but I'm not sure the  
purpose of simple CPE security as we have currently envisioned it is  
achievable without interfering with such innovation.  The people who  
want to be "protected" by these packet filters are mainly concerned  
with keeping the innovations of malware developers from interfering  
with their private network resources.

In other words, the problem as some see it is that we would all feel  
safer if there were better ways to filter out those things that don't  
currently exist at the time the CPE firmware is mastered.  I wish we  
had more guidance from the IAB about such matters... I know what my  
manager is telling me: don't let anything through unless we know what  
it is.

> extension header format, not all headers conform to this format, so  
> it may or may not be possible to look beyond an unknown header in a  
> packet.

Perhaps, the 6MAN working group could be persuaded to declare a  
particular format for future extension headers that are expected to  
have a cleartext "next header" field that packet filters can  
process?  I'm not sure how much of a problem this is really going to  
cause, though...

(In fact, it occurs to me that we have routing headers and hop-by-hop  
headers, but wouldn't it make sense to have an extension header  
format defined specifically for policy-enforcement points like  
firewall devices?  Just riffing off the top of my head there...)

> PMTUD is mentioned but no language about allowing the required  
> packet too big messages through. This is extremely important, PMTUD  
> black holes are a big problem, and some of the IPv4 worarounds  
> aren't available in IPv6. It may even be useful to allow the CPE to  
> advertise a reduced MTU on the LAN side to work around upstream  
> PMTUD breakage, although it wouldn't be a good idea to enable this  
> by default, IMO.

I thought I included that.  Do you have suggested language for  
improving R12, R13, R23 and R24?  Perhaps, you are concerned about  
SCTP, DCCP and future transport layer protocols?

> firewalls: diffserv bits in the IP header, ECN, TCP options in  
> general and window scale in particular. Do we need to say anything  
> about these? (Some firewalls ignore the window scale option but  
> then block "out of window" segments.)

Hmm.  Sounds strangely familiar.

We might be getting ahead of the BEHAVE group on the subject of TCP  
stateful packet filtering behavior, but that's probably not a bad thing.

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

---

From: "Suresh Krishnan" <[email-masked]>
Date: Tue, 4 Dec 2007 19:18:02 -0500

Hi James,

> process?  I'm not sure how much of a problem this is really going to  

I wrote a draft about this in the old ipv6 wg. Everyone said it was a good idea but it was too late. Take a look at it and let me know if this helps in any way

http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr-00

Thanks
Suresh

---

From: "Erik Kline" <[email-masked]>
Date: Tue, 4 Dec 2007 22:00:29 -0800

> http://tools.ietf.org/html/draft-krishnan-ipv6-exthdr-00

This seems like a pretty useful thing to me, actually.  Are you
considering reproposing it to 6man for discussion?  +1 from me for
re-starting the discussion.

---

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 5 Dec 2007 01:45:19 -0500

Hi Erik,
  Thanks for your note of confidence. I have not thought about resubmitting it to 6man yet. But if enough people think it needs to be done, I would love to revise it.

Thanks
Suresh

---

From: Norbert Bollow <[email-masked]>
Date: Wed, 5 Dec 2007 10:47:41 +0100 (CET)

> > process?  I'm not sure how much of a problem this is really going to  

IMO this kind of issue should be addressed in order to prevent
problems from arising, without waiting for potential problems
to show up.

> I wrote a draft about this in the old ipv6 wg. Everyone said it was
> a good idea but it was too late. Take a look at it and let me know
> if this helps in any way.
> 

Looks good to me.  (Belongs in 6MAN.)

Greetings,
Norbert.

-- 
Norbert Bollow <[email-masked]>                      http://Norbert.ch
President of the Swiss Internet User Group SIUG    http://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 31 Dec 2007 17:46:14 +0100

Under the heading "better late than never"...

> that argument past my security advisors.

Maybe a bit more text can clarify the intention of especially the  
second bullet?

> layer headers.  Is there another option available?

Nothing that works reliable and/or makes the security people happy...  
I'm starting to lean towards the position that an important job of  
this document is also to specify what should NOT be filtered.  
Considering that, I think it's reasonable to say that packets with  
unrecognized headers should be filtered, but we need a list of headers  
that must be recognized so that filtering can happen on what follows  
that header. This list would contain at least:

- fragment header
- IPsec AH and ESP (without encryption, otherwise the next header  
isn't visible)
- routing headers for mobility
- shim6  :-)
- hop-by-hop headers?

> The people who want to be "protected" by these packet filters are  
> mainly concerned with keeping the innovations of malware developers  
> from interfering with their private network resources.

Ah, yes, but these filters both apply to people who want to be  
protected and people who don't care much to be protected. (If they're  
really strongly against it they'll find out how to disable the filter,  
hopefully.)

So the "a few security measures is good, so a lot of them must be  
really good" logic that people with "security" in their jobtitle  
usually employ can't dictate what happens here.

> improving R12, R13, R23 and R24?

(I'm looking at rev 01 now, not sure how much has changed.)

R12 and R23 only talk about unreachables. However, with IPv6 too big  
is no longer a subclass of unreachable, so it must be mentioned  
explicitly.

> Perhaps, you are concerned about SCTP, DCCP and future transport  
> layer protocols?

No... I probably should be, though.  :-)

> stateful packet filtering behavior, but that's probably not a bad  

Can we say something useful about window scale? "Monitor the window  
scale option" would be good, but probably not enough: with just  
stateful filtering, it's possible to reestablish lost state from an  
outgoing packet in the middle of a session. Assuming wscale=0 in that  
case would be bad. Would it be harmful to skip the in-window check? If  
not, can we come up with a reasonable upper bound window scale that  
can be assumed in such cases? I'm thinking someone behind a consumer  
CPE would be needing a window of no more than about 256 MB (gigabit  
ethernet and 2000 ms RTT) but that may be a bit on the high side...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 31 Dec 2007 18:42:33 +0100

> is no longer a subclass of unreachable, so it must be mentioned  

And it would also be good to keep state for outgoing pings/traceroutes  
not only for their intended purpose but because ping makes it easy to  
trigger and/or debug PMTUD manually if needed.