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

From: Tobias Gondrom <[email-masked]>
Date: Wed, 16 Oct 2013 22:08:51 +0100

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors. Document editors and WG chairs should treat these
comments ust like any other last call comments.

This ID is Standards Track and and updates RFC 2460 such that the first
fragment of a packet MUST contain the entire IPv6 header chain.

The security considerations section is good. In fact the whole draft's
objective is to solve a potential security problem with super-large IPv6
header chains and enable reliable stateless packet filtering for IPv6.

COMMENTS:
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?

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?

Best regards, Tobias

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Oct 2013 19:12:05 -0300

Hi, Tobias,

Thanks so much for your review! -- Please find my comments in-line...

> deployments with large IPv6 header chains beyond the first fragment

No.

> previous paragraph and should avoid inconsistencies within the network

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,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 16 Oct 2013 23:34:41 +0100

>> deployments with large IPv6 header chains beyond the first fragment

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?

> drop, you SHOULD send an ICMPv6 error message", I guess.

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". Question: I assume from your answer,
most intermediate systems just pass through without checking that the
header conform to updated 2460, i.e. header ends within the first
fragment? In the end, I have no strong feelings about this, i.e. ok with
both (MAY and SHOULD).

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.

Best regards, Tobias

---

From: Fernando Gont <[email-masked]>
Date: Wed, 16 Oct 2013 21:59:21 -0300

> (2) we have no data at all and therefore don't know what we will break

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

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

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

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 17 Oct 2013 09:16:56 +0100

Thank you for your answers.
All the best, Tobias