On 19 Jul 2012, at 15:20 , Fernando Gont wrote: >> 1) I'd prefer this draft say that such illegal packets MUST >> be dropped, but then also say that the device dropping the >> packet MAY send an ICMPv6 Parameter Problem control message >> back to the (alleged) sending node. A brief sentence >> suggesting, but not requiring, that implementations make >> the sending of the ICMPv6 message configurable also would be >> sensible. > > Should we make this latter bit (about this being configurable) > a MAY, or would you prefer to have non-RFC2119 language?
I believe this configurability is really desirable. It isn't a big burden for an implementer, as it is simply an on/off flag, but we don't want to require it. So I would suggest either use "SHOULD support configuration of whether an ICMPv6 error/diagnostic message is sent" (edit to preference) OR (more simply) avoid using RFC21109 ALL-CAPS wording and still urge that implementers support this as a configurable setting as part of supporting "local operational policy". > 2) For the situation where an IPv6 packet is dropped for this >> specific reason, I'd suggest that the "Reason Code" registry >> for an ICMPv6 "Type 4 - Parameter Problem" message be updated >> with a new focused reason code defined. As a straw man, >> I'd propose adding this new entry to that registry, >> as part of this proposal: >> >> CODE NAME/DESCRIPTION >> 3 IPv6 Initial Fragment missing upper-layer protocol header >> >> Of course, this means an "IANA Considerations" section >> update for the I-D would be in order. > > I find your suggestion acceptable. Can others please weigh in? > > Minor note: May be the description for the error code should be along > the lines of "IPv6 First Fragment missing entire IPv6 header chain"? > (I'm just thinking of IPv6 packets with no upper layer protocol, which > would remain legal, but would not have an "upper layer protocol header") I don't object to the rephrasing of the name/description. Ideally the name/description field is relatively short. >> 4) Security Considerations ought to note the importance of >> deploying Source Address Forgery Prevention filters, in >> order to reduce the threat of an adversary forging an >> illegal packet with contains a victim/target's IP address >> in the Source IPv6 Address field of the illegal packet. >> [RFC-2827, RFC-3704] > > I have no problem with this. > However, should we really elaborate on this topic, > since it applies to all ICMPv6 error messages and > hence is probably a topic belonging to e.g. RFC 4443? I think a brief reminder here is appropriate, in part because this draft increases the attack surface a bit, by making illegal a previously-valid, if very odd, IPv6 packet construct. I would not object to including the phrase "...as with all ICMPv6 error/diagnostic messages..." as part of that brief description of the concern. Cheers, Ran -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
