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
> <brian.e.carpen...@gmail.com> 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: internet-dra...@ietf.org
>> Reply-To: internet-dra...@ietf.org
>> To: i-d-annou...@ietf.org
>>
>>
>> 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
>> i-d-annou...@ietf.org
>> 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
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
