[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-v6ops-cpe-simple-security-00
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.
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.
Some things that may deserve attention in the draft:
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?
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.
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.
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.
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?
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.
--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering