On Thu, 21 Aug 2014, Fernando Gont wrote: > On 08/21/2014 11:53 AM, C. M. Heard wrote: > > On Thu, 21 Aug 2014, Fernando Gont wrote: > >> On 08/20/2014 04:20 PM, C. M. Heard wrote: > >>> General comment on Section 4, advice about options: should the > >>> advice be nuanced to distinguish between cases where an option > >>> appears in a Hop-by-Hop option header vs a Destination Options > >>> header? > >> > >> Yes. Even if te advice ends up being the same. I will check if there are > >> any options (other than the padding ones) that cane be included in > >> different EH types (of the top of my head, most of the options are meant > >> for specific EH types). > > > > As far as I could tell, the padding options are the only ones that > > are allowed to appear in both kinds of option extension headers. > > So I guess that for the most part, there's no need of a "per-EH-type" > kind of policy for IPv6 options?
I'm not sure I'd quite say that. For one thing, I think you agreed that the advice should be to discard packets with options that appear in the wrong kind of options header. So the recommended policy for a given option would depend on the type of option header in which it appears. But that doesn't mean that you need to write a separate section for each option type / EH type combination. Also, in the case of unknown options, or RFC3692-style experimental options, if the default action (ignore or discard, depending on the upper two bits of the option code) is deemed too permissive, then there is clear benefit to allowing a different policy depending on the type of option header. Finally, I could also see a case for an intermediate box to perform detailed scrutiny of stuff in a HbH option header but to just pass all stuff in a Destination Options header -- not just because of greater security issues with HbH but because of implementation constraintes (HbH is in a fixed position and can appear only once). That would be a global per-EH-type kind of policy. I'm putting these last two things on the table mainly as food for thought. Thanks Mike Heard _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
