Re: [secdir] secdir review of draft-ietf-6man-oversized-header-chain-08

[Fernando Gont <[e-mail]>]

On 10/16/2013 07:34 PM, Tobias Gondrom wrote:
>>> 1. A question, less from a security, but interoperability perspective:
>>> is there any deplyoment data on any potential backwards compatibility
>>> issues with current IPv6 deployments? Namely are there noteworthy
>>> deployments with large IPv6 header chains beyond the first fragment
>>> currently in deployment?
>> No.
> 
> Does this "No" mean:
> (1) there are no noteworthey deployments or does it only mean
> (2) we have no data at all and therefore don't know what we will break
> with the update?

There are no specified use cases for such oversized header chains (for
instance, look at the extension header types and options specified so far).

Besides, what I've seen and what others have indicated is the same: with
the addition that any intentional use of extension headers typically
leads to packet drops (see draft-ietf-6man-ext-transmit-05.txt).


>>> 2. section 5 third paragraph:
>>> I wonder whether we should be more strict and replace the "MAY" with a
>>> "SHOULD"?
>>> This would make intermediate behavior consistent with the host from the
>>> previous paragraph and should avoid inconsistencies within the network
>>> topology?
>> IIRC, the "intermmediate systems MAY drop" is so that intermmediate
>> systems are not required to process the entire header chain. -- i.e.:
>> "If you want to drop such packets, you're free to... but we don't
>> require e.g. routers to process the entire IPv6 header chain to find
>> whether the entire header chain is present and then decide whether to
>> drop or not".
>>
>> OTOH, the "MAY send an ICMPv6 error message" could be changed to "if you
>> drop, you SHOULD send an ICMPv6 error message", I guess.
>>
>> Thanks,
> 
> I see. Actually I meant both, but let's look at them separately:
> 
> 1. "intermmediate systems MAY drop"
> Actually a "SHOULD" does not require them either, but substantially
> encourages more than the "MAY".

An implementation that does not follow SHOULDs is said to be
"conditionally complaint" where in our case, we deem a middle-box that
doesn't drop such packets as fully-cumpliant  hence the "MAY".

If a middle-box does not really need to look at the upper-layer header,
then requiring (SHOULD) it to look at the header chain just to drop the
offending packets is rather overkill.


> Question: I assume from your answer,
> most intermediate systems just pass through without checking that the
> header conform to updated 2460,

Well, packets that do not contain the entire IPv6 header chain in the
first fragment are currently RFC2460-compliant -- that's exactly why
we're pushing this document.



> 2. For the ICMPv6 error message, you are right that should be a "SHOULD"
> not a "MAY" as it is on the condition of the dropped packet.

I will change this unless anyone objects (or points out something I may
have missed).

Thanks!

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