Re: [OPSEC] review for draft-ietf-opsec-ip-security-01

[Fernando Gont <fernando at gont.com.ar>]

Hello, Andrew,

Thanks so much for the thorough review! (and sorry for the "delay" in my
response...)

I'll respond to those comments that I think that need some
clarification. (the rest of them have been applied ot the last rev of
the document).



> [Page 8]:
> 
> "3.3. TOS ..." -> RFC1349 is obsoleted by the RFC2474 (DSCP), so this
> chapter needs a rewrite.

Are you arguing that I should eliminate the TOS discussion? Or that DSCP
should be put into the main header, and the discussion of TOS be
relegated to a somewhat minor section?



> [Page 9]:
> 
> "3.4. Total Length..."
> 
> The section talks about the corner cases with discrepancy of length
> value in the header and the actual packet length, but does not discuss
> any potential interaction with EMTU_R limitations in case there are any.

mmm... not sure what you mean. Could you clarify this one?



> 9kb limit - the document should have some specific references to the
> stacks that have it. Also, probably the reference to the RFC1122 (at
> least for the terminological definition of the EMTU_R?)

Rather than stating that there are stacks that *have* this limitation,
the I-D states that virtually all stacks *can* reassemble datagrams of
at least 9KB.



> [Page 11]:
> 
> "3.5.2. Possible security improvements"
> 
> TODO - discussion of a quality of IP ID of being able to provide a
> "fingerprint" of the remote host.

You mean you could fingerprint the host by "figuring out" the algorithm
used to set the IP ID, or what?




> [Page 17]:
> 
> "Fingerprinting the physical device from which the packets originate" -
> 
> orphan word sequence.

Not sure what you mean....



> [Page 24]:
> 
> "Enforce a limit on the maximum number of options" - to me this looks a
> bit of a dangerous recommendation in this form, as it would cause
> arbitrary hard limits set by middle devices, resulting in creation of
> "IP Option MTU". (Not that anyone is adding a lot of IP options anyway
> these days, so it is more a theoretical nitpick :-)

Well, just pick a very large limit that will never limit anything, and
that's it.



> [Page 31]:
> 
> LSRR, SSRR and RR options - can their restrictions be combined as much
> as possible ? To me they look largely similar, and the repetition is a
> cause for potential mistakes, IMHO.

I agree that repetition is a potential source for mistakes, and that
conceptually speaking, they *could* be combined. However, I think it's
useful to be able to read whatever you need to know about each option in
a single section. And that of having "repeated" stuff allows me to use
"descriptive "acronyms" for each option ("LSRR.length" vs.
"SSRR.length", etc.). Please let me know if you feel strongly about this
change.



> [Page 42]:
> 
> Man in the middle threat mention for DSCP: is this the only field for
> which the MITM attacks are a concern ?

I reviewed the DSCP section, but found no discussion of MITM attacks.
Could you quote the text you're referring to?



> [Page 51]:
> 
> The sequence# check: should here be a reference to the section 3.4.3 of
> rfc2406 as a pointer to what constitutes the "valid sequence#" ?

Would just a pointer (reference) address your comment?



> Step three: should there be more specifics about some randomization for
> the process of dropping ?

Hints? (Argue something like "it's recommended that fragments are
flushed on a random basis" or the like?)




> Also - this algorithm omits the frequently used NAT-T (essentially IPSEC
> over UDP/4500)

Could this really be incorporated in the algorithm?




> [Page 52]:
> 
> "virtually impossible" - I'd replace this with "harder" :) And, as the
> MITM is mentioned for DSCP, I'd not make the task easier for IPSEC
> specifically :) the algorighm which is supposed to protect IPSEC should
> be able to resist the on-path attacker.

Well, I don't think you could protect IPsec traffic that relies on
fragmentation. If a have access to the IPsec fragments, I could simply
forge fragments that would lead to a failure in the reassembly process.



> [Page 53]:
> 
> "Additionally, given that many middle-boxes such as firewalls create
>    state according to the contents of the first fragment of a given
>    packet, it is best that, in the event an end-system receives
>    overlapping fragments, it honors the information contained in the
>    fragment that was received first."
> 
> received first if there was a box behind the middlebox that has
> reordered the packets afterwards, or if there was no such box ? :-)

Not sure what you mean.



> If the two received fragments contain conflicting information, we do not
> have enough info to discern which of the two is "correct", IMHO. So, we
> should mark the corresponding packet as "bad", 

Isn't this more aggressive than what the existing text recommends?


> treat the reassembly as
> usual, and then drop it with an auditable event. (not drop immediately
> in order to avoid the DoS where colliding fragments would be dropped and
> cause the accumulation of the remaining fragments till the max
> reassembly timeout occurs).

I agree with this "remaining fragments thing". However, obvious
question: how long should we wait? This might close one door of attack,
but open another one....




> [Page 54]:
> 
> sending with high precedence values: ingress filtering ?

ingress-filtering based on the IP addresses, you mean?



> (Also, with the DSCP/ToS duality, worth doublechecking on how does it
> translate to real forwarding devices?)

mmm... not sure what you mean.



> [Page 55]:
> 
> Address resolution: the passage about storing the packets for a long
> time on the router - isn't it something that should be directly
> discouraged, precisely because of its big impact ?

What specific behavior would you recommend?




> [Page 56]:
> 
> "Dropping packets":
> 
> should be mentioned that all dropped packets should be *counted*
> somewhere ?

I think I forgot to include the "this should be logged" here. But will
do in the next rev. (As you may have seen, I added a "this should be
logged" statement in every passage of the I-D that recommends to drop a
packet).

Thoughts?

It would be great if we could converge on all the above items, so that I
can address these remaining issues in te next rev of the I-D.

Thanks again for your feedback!

Kind regards,
-- 
Fernando Gont
e-mail: fernando at gont.com.ar || fgont at acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1