Hello Brian,
(as I expected, you were the first to react - didn't let me down on that one ;-)
We have a different starting point to look at "things" :
as I wrote, one reason for incorrect packets might be
an attacker looking for unexpected behaviour, undesirable side effects.
I understand and appreciate your point of view is sometimes different :
"What is so dangerous about an unknown extension header? The receiving
host will either understand it or drop it."
--> perhaps the attacker looks for an implementation that does poor
checking on extension header codes or option types.
If handling is via a table without proper index value checking,
perhaps such a kernel will crash upon receiving the unexpected packet.
In my opinion : the firewall is what should protect such a (poor, I
agree) server.
(because the server behaves correct on known codes and combinations)
--> perhaps both partners do understand the extension header code,
and (ab)use it to create a hidden data channel
in a conversation that looks - at layer 4 + upwards - like one thing
but carries undesired data in the IPv6 header (+ extensions).
Again, in my opinion : what use is any "Data Leakage Prevention" solution
if security equipment allows unknown extension headers and option codes
to pass without problem ?
(when refering to multiple fragmentation headers)
"But since any receiving host should obviously drop such
malformed packets, it would be fine for firewalls to drop them too."
--> (we agree there ;-) but according to RFC they are *not* illegal, are they ?
RFC 2460 does not forbid two or more fragmentation headers.
One does not expect them, but again, I'm vigilant for the attacker
in search of undesired side effects.
And I think we've had, since the 90's a lot of security issues that
had "unexpected" / "never thought we'd see this combination for real"
packets arriving at some server.
(and not only with IP(v4) - also in layer4 and higher (L5-L7) protocols !)
That is why I feel uncomfortable with any security advice that states :
check what you understand, and allow what you do not ...
Kind regards,
Marc
On Mon, Nov 19, 2012 at 5:37 PM, Brian E Carpenter
<[email protected]> wrote:
> 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
>>> --------------------------------------------------------------------
>>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
