Subject: [Int-dir] Sheng's review of draft-ietf-opsec-dhcpv6-shield (was: Re: Mail regarding draft-ietf-opsec-dhcpv6-shield)

From: Fernando Gont <[email-masked]>
Date: Tue, 09 Dec 2014 08:05:15 -0300

Hi, Joel & Ted,

I never received Sheng's review (neither the authors nor the
corresponding aliases were among the recipients list). But I'm
responding to Sheng's feedback below.

On 12/08/2014 03:17 AM, joel jaeggli wrote:
> Thanks ted,
> 
> I think a response should be forth-coming.
> 
> joel
> 
> On 12/7/14 8:01 PM, Ted Lemon wrote:
>> I requested a review of this document from the intarea
>> directorate and got a response from Sheng.   There may be another
>> review from Ralph later.   Could you take a look at Sheng's
>> review and respond to it?   If you do, please keep me in the
>> conversation.
>> 
>> Thanks!
>> 
>> Begin forwarded message:
>> 
>>> From: Sheng Jiang <[email-masked]> Subject: Re:
>>> [Int-dir] DHCPv6 expert review of
>>> draft-ietf-opsec-dhcpv6-shield Date: December 7, 2014 at
>>> 9:12:16 PM EST To: Ted Lemon <[email-masked]>, Bernie
>>> Volz <[email-masked]> Cc: "<[email-masked]>"
>>> <[email-masked]>
>>> 
>>> Hi,
>>> 
>>> I have reviewed draft-ietf-opsec-dhcpv6-shield as an assigned 
>>> reviewer by the Internet Area directorate. Below is my review 
>>> comments:
>>> 
>>> Overall, this document proposes an useful mechanism to
>>> protecting hosts connected to a switched network against rogue
>>> DHCPv6 servers. The proposed mechanism and text are mature.
>>> However, I have one major and several minor technical
>>> comments:
>>> 
>>> Major technical comments:
>>> 
>>> In section 5, rule 3, the document propose: "When parsing the 
>>> IPv6 header chain, if ... the packet contains an unrecognized 
>>> Next Header value, DHCPv6-Shield MUST drop the packet". This 
>>> default behavior is against RFC7045, which has "Intermediate 
>>> forwarding nodes SHOULD NOT discard packets containing 
>>> unrecognised extension headers." Although RFC7045 does allow 
>>> "default configuration MAY drop such packets", I do not see a 
>>> necessary reason why we drop such packet here. This seem not 
>>> relevant to rogue DHCPv6 message at all.

The reason is that since there is no uniform format for IPv6 extension
headers (yes, I'm aware of RFC6564, but please check
draft-gont-6man-rfc6564bis-00), such an EH could be leveraged to
conceal a malicious DHCPv6-server packet from the DHCPv6-Shield device.

>>> Minor comments:
>>> 
>>> a) DHCP snooping has been understood widely. Why not continue
>>> use the similar name, DHCPv6 snooping? A new name "DHCPv6
>>> shield" may imply the mechanism is different.

Good question. :-) Will chat with the other c-authors about this...

>>> b) In section 5, rule 1, rationale part. Does an
>>> implementation that inspect IPv6 headers often enforce a limit
>>> on the number of bytes? I personally doubt any implementors
>>> would do so. Why one will even do this? So, although I agree
>>> the technical point here, I fail to understand the necessity
>>> for it.

Yes, implementations do that. Typically because they copy the first N
bytes to some fast memory to do the inspection.

>>> c) Rule 2 section 5. Again, this rule is technically right,
>>> but not really relevant to rogue DHCPv6 messages. Therefore, I
>>> think the "MUST" is too strong here.

You get false negatives if you don't enforce this rule.

>>> d) The third last paragraph of section 5, this section seems
>>> all relevant to rule 2. The better place is within the relation
>>> of rule 2 or a discussion part of rule 2.

Below all the filtering rules there's a summary discussion of what
eahc rule is doing... that's it.

>>> e) The second last paragraph of section 5, "if the
>>> DHCPv6-Shield device fails to identify the upper-layer protocol
>>> as a result of the use of fragmentation". This may be down to
>>> implementation, but it is still unclear here: how a DHCPv6
>>> device decides fragmented packets (not the first fragmented
>>> packet) is identify the upper-layer protocol as a result of the
>>> use of fragmentation and how it may be failed.

Please see RFC7112

>>> f) The first paragraph of section 7. This paragraph describe
>>> the scope of this document. It should belong to introduction
>>> section rather than security consideration.

Will check with the other co-authors what they think. I'd note,
though, that this is a pretty normal Sec Cons section (i.e., to
explicitly note which attack vectors are not covered).

>>> g) This document does not mention Secure DHCPv6 at all. It is 
>>> relevant, I believe.

Personally, I wouldn't mind including a reference to it along the
lines of

"[DHCPv6] secure allows for authentication of DHCPv6-server packets if
the IPv6 addresses of the DHCPv6 servers can be pre-configured at the
client nodes".

However, it's not clear to me hw
http://tools.ietf.org/id/draft-ietf-dhc-secure-dhcpv6-07.txt ralates
to our work. Clearly, our goal is protection that requires zero
configuration on the client side, and minimum configuration on the
network/switch side.

Thanks!

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

---

From: Sheng Jiang <[email-masked]>
Date: Wed, 10 Dec 2014 05:42:51 +0000

>corresponding aliases were among the recipients list). 

Hi, Gont,

I was assigned reviewer by the Internet Area directorate recently. My review was sent to intarea directorate this Monday. Ted forwarded to you at the first time. Discussion in line.

>But I'm

How? The analysis, or at least a demonstration of such attack, should be in the document. If the convincible analysis showed such behavior are necessary, I am fine with it. But for now, such content are missing in the document.

>bytes to some fast memory to do the inspection.

Yes, offline inspection does that. But we are talking about online real time filter, aren't we?

>You get false negatives if you don't enforce this rule.

Yes, I know the damage. My point is it is a generic rule for all IPv6 forward nodes. It makes it optional for DHCPv6 shield/snooping.

>>>> use of fragmentation and how it may be failed.

Please add clear reference (it should point to a certain section of RFC 7112) in the document.

>configuration on the client side, and minimum configuration on the

You have referred to an expired document. The active one is https://tools.ietf.org/html/draft-ietf-dhc-sedhcpv6

I think they are complementarity to each other. Neither of these provide complete security mechanism for all deployment. So, one more sentence could state the relation:

While DHCPv6 shield/snooping filters the server messages from untrusted port of layer-2 devices, the Secure DHCPv6 [] allows DHCPv6 clients to make a leap of faith that a server is trustworthy.

Best regards,

Sheng