Subject: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt]

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Nov 2012 11:02:31 +0000

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-masked]
Reply-To: [email-masked]
To: [email-masked]

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-masked]
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

---

From: Marc Lampo <[email-masked]>
Date: Mon, 19 Nov 2012 11:54:55 +0100

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 ?

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.

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 !
Because : how can a firewall distinguish between a newly defined
extension header or type in an existing header
and a potential malicious character combination ?

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

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.
Perhaps the appropriate WG should not be to enthousiastic
in adding headers or options in the first place ?!

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)

And, in the same line of thinking, RFC 2460 does not seem to limit
the number of extension headers ?!
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 ...)
((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 ...))

Kind regards,

Marc

On Tue, Nov 13, 2012 at 12:02 PM, Brian E Carpenter
<[email-masked]> wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 19 Nov 2012 16:37:26 +0000

Hi Marc, thanks for the comments.

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

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

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

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

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

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

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

>  (presently, it only addresses type and content of extension headers,

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.

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

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

>   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

---

From: Marc Lampo <[email-masked]>
Date: Mon, 19 Nov 2012 20:48:28 +0100

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 19 Nov 2012 15:01:57 -0500

Taking things out of order:

If you are really going to lock covert channels, then you will have to 
block HTTPS except to known sites (and check the hostname against the IP 
address, etc...)  That has not, and I hope is not, and acceptable design 
space for the IETF.

With regard to unknown extensions and broken implementations, there are 
two issues.  First, as Brian pointed out earlier, firewalls need to have 
dates.  If you are not willing to do that, then you will be vulnerable 
anyway.  Second, since the firewall does not know what already defined 
extensions are mis-implemented in some host, you are already vulnerable 
on this front.  In fact, a broken implementation trying to process 
something is far more likely than a broken default case.

Yours,
Joel M. Halpern

---

From: Marc Lampo <[email-masked]>
Date: Tue, 20 Nov 2012 08:53:54 +0100

Hello Joel,

do you mean that
"because there are already other possibilities for covert channels,
 this WG should not bother if its work creates yet another one" ?

In the book "IPv6 Security", lower half of page 32,
 (ISBN-10: 1-58705-594-5  -  ISBN-13: 978-1-58705-594-2)
the authors refer to the destination extension header as a "covert channel".
And quite correctly so, in my opinion :
  the PadN option allows two parties to exchange arbitrary data
  that looks, L4 upwards, like HTTP/DNS/ping6
  (especially DNS - a covert channel by itself ! - is often allowed
very liberally).

Kind regards,

Marc

On Mon, Nov 19, 2012 at 9:01 PM, Joel M. Halpern <[email-masked]> wrote:
> If you are really going to lock covert channels, then you will have to block
> HTTPS except to known sites (and check the hostname against the IP address,
> etc...)  That has not, and I hope is not, and acceptable design space for
> the IETF.
>
> With regard to unknown extensions and broken implementations, there are two
> issues.  First, as Brian pointed out earlier, firewalls need to have dates.
> If you are not willing to do that, then you will be vulnerable anyway.
> Second, since the firewall does not know what already defined extensions are
> mis-implemented in some host, you are already vulnerable on this front.  In
> fact, a broken implementation trying to process something is far more likely
> than a broken default case.
>
> Yours,
> Joel M. Halpern
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Nov 2012 08:22:58 +0000

>   (especially DNS - a covert channel by itself ! - is often allowed

I don't think we should confuse the discussion of firewalls attempting to
prevent malicious attacks with snooping for covert channels. That is a
completely different aspect of security.

   Brian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 20 Nov 2012 10:05:42 -0500

Yes, I think that having the IETF attempt to define rules for avoiding 
covert channels in IPv6 packets is actively counter-productive.  It 
impedes innovation without providing a meaningful increase in security.

Yours,
Joel

---

From: Ray Hunter <[email-masked]>
Date: Mon, 26 Nov 2012 21:35:16 +0100

+1.

If anyone wants to be able to guarantee blocking any ability to
construct a covert channel over a communication path, then they should
probably employ a messaging protocol that is fully defined from the
ground up using a formal grammar. Then they could check all (application
level) messages against that grammar at all points along the
transmission path. But that's almost certainly not going to be an
Internet protocol.

I also suspect a number of IPv6 security books are going to have to be
rewritten, and that "stateful firewall" devices (or indeed any stateful
mechanisms located at the entrance to a site) are themselves likely
going to become the target of (DoS) attacks. I therefore suspect many of
these functions are going to have to be devolved, perhaps all they way
to the end hosts, or even the application layer itself.

regards,
RayH

Joel M. Halpern wrote:
>>>> (as I expected, you were the first to react - didn't let me down on
>>>> that
>>>> one ;-)
>>>>
>>>> --> (we agree there ;-) but according to RFC they are *not*
>>>> illegal, are
>>>> they ?
>>>>    (and not only with IP(v4) - also in layer4 and higher (L5-L7)
>>>> protocols
>>>> !)
>>>>
>>>>>> seems in contradiction with what a firewall has to do : inspect
>>>>>> traffic
>>>>>> !
>>>>>
>>>>>
>>>>>>    (some hacker might be searching for obfuscation or
>>>>>> undesireable side
>>>>>> effects ?)
>>>>> This draft is about making the Internet transparent to extensions,
>>>>> so I
>>>>> think
>>>>> misordered extension headers, but if so, I think that deserves a
>>>>> draft of
>>>>> its own.
>>>>>
>>>>> Overlapping fragments are forbidden (RFC 5722) but that is a
>>>>> different
>>>>> matter.
>>>>>>     straight answer on how its product would behave in that
>>>>>> situation
>>>>>> ...))
>>>>>
>>>>>

---

From: Mark Smith <[email-masked]>
Date: Tue, 27 Nov 2012 01:02:27 -0800 (PST)

+1 

The packets themselves might be normal, but the packet arrival rate might be where the covert information is conveyed.

----- Original Message -----
> From: Ray Hunter <[email-masked]>
> To: Joel M. Halpern <[email-masked]>
> Cc: 6man <[email-masked]>
> Sent: Tuesday, 27 November 2012 7:35 AM
> Subject: Re: Re: [Fwd: I-D Action: draft-carpenter-6man-ext-transmit-01.txt]
> 
> +1.
> 
>>>>  issues.  First, as Brian pointed out earlier, firewalls need to 
> have
>>>>  dates.
>>>>>        perhaps such a kernel will crash upon receiving the 
> unexpected
>>>>>  packet.
>>>>>        in a conversation that looks - at layer 4 + upwards - 
> like
>>>>>  one thing
>>>>>  Again, in my opinion : what use is any "Data Leakage 
> Prevention"
>>>>>  solution
>>>>>        One does not expect them, but again, I'm vigilant for 
> the
>>>>>  attacker
>>>>>     had "unexpected" / "never thought we'd 
> see this combination for
>>>>>  real"
>>>>>>>  internal assets from potentially dangerous 
> "things" trying to get
>>>>>>>  in.
>>>>>>  Right, and the IPv6 standard says that all extension 
> headers
>>>>>>  should be
>>>>>>>     containing a defined IPv6 extension header, it MUST 
> be the
>>>>>>>  result of
>>>>>>>     an explicitly configured firewall policy, and not 
> just the
>>>>>>>  result of
>>>>>>  A firewall that doesn't understand some of the defined 
> headers is
>>>>>>  clearly
>>>>>>  explicit policy is to make sure that the network is 
> transparent by
>>>>>>  default,
>>>>>>  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.
>>>>>> 
>>>>>>>     but provides documentation to selectively allow (and 
> verify)
>>>>>>>  others
>>>>>>>  or
>>>>>>>  Anyway, since IPv6 should be considered to be "in 
> production"
>>>>>>>  already,
>>>>>>>  not addressed in this draft (nor, after rereading RFC 
> 2460 for this
>>>>>>>  subject)
>>>>>>>  What should security equipment do if it detects the 
> order is not
>>>>>>>  respected ?
>>>>>>>     (presently, it only addresses type and content of 
> extension
>>>>>>>  headers,
>>>>>>>      not the order)
>>>>>> 
>>>>>> 
>>>>>>  this aspect is out of scope. I'm not sure that there 
> are any attacks
>>>>>>  based on
>>>>>>  Nor the amount of padding. This is where the 
> fragmentation-based
>>>>>>  attack
>>>>>>>     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 ?
>>>>>>>  ((no firewall vendor I've contacted so far has been 
> able to give
>>>>>>>  me a
>>>>>>  Again, I'm not sure there's a real attack there - 
> if there is, it
>>>>>>  might
>>>>>>>>  A New Internet-Draft is available from the on-line 
> Internet-Drafts
>>>>>>>>  directories.
>>>>>>>> 
>>>>>>>> 
>>>>>>>>       Various IPv6 extension headers have been 
> defined since the
>>>>>>>>  IPv6
>>>>>>>>       standard was first published.  This document 
> updates RFC
>>>>>>>>  2460 to
>>>>>>>>       headers and with any that are defined in 
> future.  It also
>>>>>>>>  specifies
>>>>>>>>  Administrative Requests: 
> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>> 
>>>>>  Administrative Requests: 
> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>