[secdir] Secdir review of draft-ietf-conex-tcp-modifications-09

["Takeshi Takahashi" <[e-mail]>]

Hello,

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.

This document is almost ready, but I have a couple of clarification
questions.

[summary of this document]

This document is an experimental draft, which talks about the modifications
needed to use ConEx with TCP.
Depending on the status of receivers' protocol support, the accuracy of the
congestion control we can take may differ.
Indeed, the receiver may or may not supports SACK, ECN, or accECN.
This document thus considers assorted cases of receivers' protocol support
status and provides the solution (or guideline) to use ConEx with TCP.

[clarification question]

My comment focuses on Section 10 "Security Considerations".
I am not familiar with ConEx (though I have read the related drafts in these
days), so allow me to ask basic questions.

Question 1: on the last two sentences in the second paragraph: " Instead the
sender can choose to mark inaccurately, which will only increase the
likelihood of loss at an audit function. Thus the receiver will only harm
itself. "

I can understand that "the sender can choose to mark inaccurately, which
will only increase the likelihood of loss at an audit function."
Then, would it be the "sender" who will harm itself?
Why do you say that "the receiver will only harm itself"?

I think "mark inaccurately" in this case means that the sender marks less
than actual congestion states.
Does this understanding correct?
Or, if the sender marks more than actual congestion states, does that also
increase the likelihood of loss at an audit function?

Questions2: on man-in-the middle attacks.

Is it better to address the cases of TCP session hijacks?
Or should I think that this issue is covered by the sentence "General Conex
security considerations are covered extensively in the ConEx abstract
mechanism"?

Thank you.

Take