Re: [v6ops] Last Call: <draft-ietf-v6ops-ra-guard-implementation-04.txt> (Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)) to Best Current Practice

[Fernando Gont <[e-mail]>]

Hi, Ran,

On 05/31/2012 03:09 PM, RJ Atkinson wrote:
>> This one is correct.
>>
>> Note that in draft-gont-6man-nd-extension-headers, we're currently
>> saying "SHOULD NOT", but this should probably be changed to "MUST NOT",
>> as you indicate.
> 
> Agree.  
> 
> "MUST NOT" seems to be functionally necessary here.

Ok, I will update the doc and resubmit, such that 6man wg is polled
about adoption of this I-D with this change 'in'.

Note: the only possible "issue" here is that with SEND, packets *might*
grow large enough to need fragmentation. However:

1) The aforementioned behaviour would be specified for traditional ND,
rather than SEND.
2) At least the packet sizes sampled in the SEND spec are not larger
than 1280 bytes
3) If you do deploy send, you don't really want to rely on
fragmentation. If you do, then an attacker could trivially "disable"
SEND by performing fragmentation (DoS) attacks.

-- Just wanted to double-check this with you before the s/SHOULD/MUST/
change.


>> We have expressed this requirement (in
>> draft-gont-6man-oversized-header-chain-01.txt) as:
>>
>>   All IPv6 packets MUST contain the entire IPv6 header chain within the
>>   first "assumed Path-MTU" bytes of the packet.  If a packet is
>>   fragmented, the first fragment of the packet (i.e., that with a
>>   Fragment Offset of 0) must contain the entire IPv6 header chain
>>   within the first "assumed Path-MTU" [RFC1981] [RFC4821] bytes of the
>>   packet.
> 
> That seems OK at first reading.  
> 
> I hope there already is text that has the effect of requiring 
> a receiving IPv6 node to drop any received ICMPv6 that hid 
> behind a Fragment Header.  

Such requirement is in draft-gont-6man-nd-extension-headers.
Essentially, draft-gont-6man-nd-extension-headers forbids the use of
fragmentation with ND, and hence this means that when it comes to ND
you'll always have the entire IPv6 header chain available in the same
packet (if you don't, the packet was fragmented, and you're required to
fragment it).

draft-gont-6man-oversized-header-chain tackles a more general problem:
since we cannot ban IPv6 fragmentation altogether for general traffic
(for obvious reasons), for the general case we require the first
fragment to include the entire IPv6 header chain (i.e., "put as many
headers as you want (including fragmentation)... but the entire IPv6
header chain must be available in the first fragment").


> One imagines the actual requirement
> for receiving IPv6 nodes might be written more generically.
> 
> As an example to clarify things, it would not hurt to explicitly 
> note that this does NOT preclude the use of TCP Jumbo data payloads, 
> but instead merely requires that all *headers*, starting from IPv6 
> base header and continuing up to & including the TCP header, 
> be present in the 1st packet.

You mean this could/should be clarified in
draft-gont-6man-oversized-header-chain-01, or somewhere else?



> This means that the RA Guard document ought to:
> (1) cite (normatively) draft-gont-6man-oversized-header-chain, 
> (2) delete Rule 4 of the RA Guard draft (which is not needed), 
> and 
> (3) add clarifying text to the RA Guard draft noting that the 
>     referenced 6MAN document ensures that RA messages that 
>     try to hide behind a Fragment Header will be dropped 
>     by the receiving IPv6 node.

But if it's agreed that packets that do not contain the entire IPv6
header chain shouldn't be there, what would be the motivation for
allowing them through ra-guard? -- Put another way, if we include a
normative reference to draft-gont-6man-oversized-header-chain, this
implicitly mean that, even with rule #4 in, the posibility of false
positives is 0 (and OTOH, leaving rule #4 in allows ra-guard to protect
'legacy' implementations.

(Me just wanting to follow your reasoning here)

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492