On 2/10/15 12:49 PM, Ted Lemon wrote: > On Feb 10, 2015, at 1:38 PM, Fernando Gont <[email protected]> > wrote: >> Not sure what the "(as opposed to an extension header)" means. >> Could you elaborate/clarify a bit? > > What I'm proposing is that unknown codes can be assumed to be > extension headers. Any known code may be either an extension header > or a protocol header, but then it's a known code, so not a problem. > But rereading the text, that parenthetical does seem unnecessary. > > Anyway, it sounds like we now have some text to argue about that we > might be able to agree on, so I will defer to you on tweaking it--I > just wanted to give you a sense of what I had in mind. The main > thing I want to avoid is a recommendation that the basic shield > algorithm by default drop unknown extension and transport headers, > but I agree that it's good to say what to do if the hardware can't > support that fully.
We got a new version of this draft on 2/25 which I kinda of lost track of in the midst of two IESG review calls. http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-opsec-dhcpv6-shield-06.txt It stops short of my interpretation of Ted's position, with the reordered and clarified test in section 3. the new explanatory text in in the security considerations: The recommendations in this document represent the ideal behavior of a DHCPv6 shield device. However, in order to implement DHCPv6 shield on the fast path, it may be necessary to limit the depth into the packet that can be scanned before giving up. In circumstances where there is such a limitation, it is recommended that implementations drop packets after attempting to find a protocol header up to that limit, whatever it is. Ideally, such devices should be configurable with a list of protocol header identifiers so that if new transport protocols are standardized after the device is released, they can be added to the list of protocol header types that the device recognizes. Since any protocol header that is not a UDP header would be passed by the DHCPv6 shield algorithm, this would allow such devices to avoid blocking the use of new transport protocols. When an implementation must stop searching for recognizable header types in a packet due to such limitations, whether the device passes or drop that packet SHOULD be configurable.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
