Subject: secid review of draft-ietf-ipv6-deprecate-rh0-01

From: "David Harrington" <[email-masked]>
Date: Mon, 24 Sep 2007 17:13:09 -0400

Hi,

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 just like any other last call comments.

-
The purpose of draft-ietf-ipv6-deprecate-rh0-01 is to deprecate a
feature of IPv6 which has been shown to have undesirable security
implications.  In particular, RH0 provides a mechanism for traffic
amplification, which might be used as a denial-of-service attack. 

As such, the whole document is a security consideration. The
vulnerability appears well-documented, and the guidelines for handling
the deprecated RH0 are clear.

I have a few comments
1) RH0 really is something we do not want to see used, right? Should
this RH be obsoleted rather than deprecated? 
2) Per BCP61, MUST is for implementers, and SHOULD is for
users/deployers. There is a MUST NOT in section 4.2 that is a
deployment decision, so this should be a SHOULD NOT. At the same time,
there is a "must" in section 4.2 that is an implementation
requirement, so this should be a MUST.
3) Section three uses "must" where MUST would seem appropriate.

David Harrington
[email-masked]
[email-masked]

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Tue, 25 Sep 2007 09:55:45 -0400

So, BCP 61's claim that MUST is for implementers and SHOULD is for
users is always something I've interpreted as non-normative and
additional explanation of RFC 2199.  Well, I' guess it is normative in
that we do not for security reasons require that security be used.

I certainly think reviewing the musts and shoulds in this case is
fine, but if the authors believe they used the right word, then leave
the text.  If there is a problem we can clean it up during iesg
evaluation.