Hi Marc, thanks for the comments.
On 19/11/2012 10:54, Marc Lampo wrote:
Hello,
(didn't see summary of discussion in Atlanta yet,
so bear with me if I would repeat something brought in there)
(and my appologies for the long email)
Paragraph 4 of the Introduction states :
"The main reason for this is that some
firewalls attempt to inspect the transport header or payload."
Is this a factual statement or do I read a negative undertone ?
It's intended to be factual. As described later, the attempt fails
if the the firewall in question does not follow the entire header
chain for one reason or another.
As a security person, I see the purpose of a firewall is to protect
internal assets from potentially dangerous "things" trying to get in.
This includes stopping traffic that is not conform to standards.
Right, and the IPv6 standard says that all extension headers should be
forwarded. That's exactly the problem.
So, to me, "attempting to inspect the transport header or payload"
is simply a basis funcionality of the firewall.
The draft already addresses the behaviour towards unknown extension
headers.
The statement, section 2,
"If a firewall chooses to discard a packet
containing a defined IPv6 extension header, it MUST be the result of
an explicitly configured firewall policy, and not just the result of
a failure to recognise such a header."
seems in contradiction with what a firewall has to do : inspect traffic
!
A firewall that doesn't understand some of the defined headers is clearly
inadequate to completely inspect the traffic. The requirement for an
explicit policy is to make sure that the network is transparent by
default,
with blocking being a human choice.
Because : how can a firewall distinguish between a newly defined
extension header or type in an existing header
and a potential malicious character combination ?
My computer annoys me very frequently with security updates. A firewall
should be updated in the same way, very soon after a new extension is
defined,
which will be a great deal less frequent than the discovery of new
viruses.
If a firewall drops extension headers (except fragmentation)
but provides documentation to selectively allow (and verify) others
or
if a firewall allows extension headers and allows the admin
to seclectively block (known) headers
they both lose in case of newly defined headers or option types :
The first one has no code to verify,
the second one has no provisions (GUI selector) to block.
I'd feel safer with the first type of firewall ...
What is so dangerous about an unknown extension header? The receiving
host will either understand it or drop it.
Anyway, since IPv6 should be considered to be "in production" already,
and security equipment is being put in place,
I hope we won't see any changes at all in this area at all.
It's broken today, so we have to do something. This draft attempts
to repair broken firewalls. Anything else will be much more drastic.
Perhaps the appropriate WG should not be to enthousiastic
in adding headers or options in the first place ?!
That would be very sad - the end of innovation in the network layer.
In fact, the IETF has not been prolific in this area, and won't be,
unless we can fix the problems caused by firewalls and DOS defence.
Another aspect of extension header (verification),
not addressed in this draft (nor, after rereading RFC 2460 for this
subject)
is the fact that rules are defined.
RFC 2460 states extension headers have a specific order.
What should security equipment do if it detects the order is not
respected ?
(some hacker might be searching for obfuscation or undesireable side
effects ?)
I suggest this draft is completed with statements on this situation.
(presently, it only addresses type and content of extension headers,
not the order)
This draft is about making the Internet transparent to extensions, so I
think
this aspect is out of scope. I'm not sure that there are any attacks
based on
misordered extension headers, but if so, I think that deserves a draft of
its own.
And, in the same line of thinking, RFC 2460 does not seem to limit
the number of extension headers ?!
Nor the amount of padding. This is where the fragmentation-based attack
mentioned in draft-ietf-6man-oversized-header-chain comes from.
Since the first field in any extension header is "next header",
nothing prevents an extension header to state the next one is of the
same type !
But two consecutive fragmentation headers don't make sense, do they ?
Yet, it doesnot seem to be forbidden.
(don't say this cannot happen, perhaps it's the hacker, in search
to obfuscate or side effects ...)
Overlapping fragments are forbidden (RFC 5722) but that is a different
matter.
Also see draft-ietf-6man-ipv6-atomic-fragments. Formally forbidding
multiple fragment headers seems a bit like overkill, since clearly
no sane host will do that.
The general issue is discussed in draft-ietf-6man-oversized-header-chain,
which aims to defeat the fragmentation attack.
((no firewall vendor I've contacted so far has been able to give me a
straight answer on how its product would behave in that situation
...))
Again, I'm not sure there's a real attack there - if there is, it might
be an attack against weak firewall code, which frankly I don't care
about. But since any receiving host should obviously drop such
malformed packets, it would be fine for firewalls to drop them too.
The concern is about firewalls that drop well-formed packets!
Regards,
Brian
On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter
<[email protected]> wrote:
Updated after the discussions in Atlanta. More discussion wanted...
-------- Original Message --------
Subject: I-D Action: draft-carpenter-6man-ext-transmit-01.txt
Date: Tue, 13 Nov 2012 02:38:38 -0800
From: [email protected]
Reply-To: [email protected]
To: [email protected]
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Transmission of IPv6 Extension Headers
Author(s) : Brian Carpenter
Sheng Jiang
Filename : draft-carpenter-6man-ext-transmit-01.txt
Pages : 8
Date : 2012-11-13
Abstract:
Various IPv6 extension headers have been defined since the IPv6
standard was first published. This document updates RFC 2460 to
clarify how intermediate nodes should deal with such extension
headers and with any that are defined in future. It also specifies
how extension headers should be registered by IANA, with a
corresponding minor update to RFC 2780.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-6man-ext-transmit
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-carpenter-6man-ext-transmit-01
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-carpenter-6man-ext-transmit-01
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
