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

[Iljitsch van Beijnum <iljitsch@muada.com>]

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

On 5 dec 2007, at 0:56, james woodyatt wrote:

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

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

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

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

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.

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

(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.  :-)

> > 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.)

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

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