[ipv6-wg] [v6ops] Extension Headers / Impact on Security Devices

> On Jun 17, 2015, at 1:14 AM, Enno Rey <erey at ernw.de> wrote:
> 
> Fred, All,
> 
> On Wed, Jun 17, 2015 at 07:41:33AM +0000, Fred Baker (fred) wrote:
>> I'm of course missing the preceding email. No problem with the cross-posting, but let's get the question on the table? Is this section 4.1's statement that "it is recommended that those headers appear in the following order"?
>> 
>> I have a hunch that an internet draft requiring headers to be in the listed order would be looked at with approbation. The issue, if any, would likely have regard to repeated Destination Option headers. However
>> 
>>   Each extension header should occur at most once, except for the
>>   Destination Options header which should occur at most twice (once
>>   before a Routing header and once before the upper-layer header).
>> 
>> seems to me fairly definitive.
> 
> I'm not so sure about this. First probably a capital "SHOULD" would have been more appropriate.

RFC 2460 doesn't use the RFC 2119 conventions. Yes, it's hard to remember now, but RFC 2119 conventions weren't always the rule; they derived from similar usage in RFCs 1122/1123 and 1812. History lesson in the presence of adult beverages if that's interesting.

> Second - and this is our main point/observation - there's too much space of interpretation for actual implementation.
> To underline this I will just cite two somewhat random sections from the study we performed on evading security controls (IDPS systems) by means of extension headers, combined with fragmentation (https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf). One of the devices (all of them latest code incl. some high-end gear) could be evaded by the following:

Cutting to the chase, on the surface it looks like most of the cases you specified conform to the sequence rule, with the exception of one that has three Destination Option Headers. What I *think* you're pointing out is (from your PDF) that this is part of a sequence of messages, one of which is fragmented, accepted by the intrusion detector, and not accepted by the ultimate host (perhaps a TCP checksum failed?), and as a result bypasses the signature that the intrusion detector is looking for. The issue wasn't that the sequence was incorrect, in most cases; it was that the intrusion detector made a different choice than the end host.

Tell me this. Would you be happier if the fragmentation rule said that the first fragment had to contain the entire IPv6 header, plus the transport layer header (for ACL support)? I think Fernando would support such a statement (I think I have "heard" him make such a statement).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: </ripe/mail/archives/ipv6-wg/attachments/20150617/f2137407/attachment.sig>