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

[Mirja Kühlewind <[e-mail]>]

Hi Take,

thanks for you feedback!

See below.

Mirja

On 26.08.2015 05:05, Takeshi Takahashi wrote:
> 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"?
>

What we wanted to say here is that if the receiver does not provide accurate 
feedback, by supporting SACK, ECN or AccECN, the sender has to estimate the 
congestion level. In this case it's the sender's choice to make a very 
conservative estimation by sending most likely too much or risking to get audit 
losses by potentially understating. Therefore by not providing sufficient 
feedback (based on SACK or ECN/AccECn), even if the receiver would be able to do 
so, the receiver can only hurt itself.

But you are right, I also had to rewrite it twice now, so I'll rephrase this to 
make it more clear.

> I think "mark inaccurately" in this case means that the sender marks less
> than actual congestion states.

yes, but remember the sender might not have sufficient feedback to actually know 
the exact congestion state and therefore has to estimate it. This can be done 
conservatively with will usually send too much marks (where the sender might 
have to pay for in some way)... or the sender might risk to send not enough 
marks which can cause additional loss.

> 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?

No.

>
> Questions2: on man-in-the middle attacks.
>
> Is it better to address the cases of TCP session hijacks?

I don't think there is an additional risk of actual hijacking (compared to TCP 
without ConEx).
As ConEx does neither improve nor worsen this, it's not discussed. Or what 
exactly do you mean by '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"?

Yes, the abstract mechanisms draft lists two potential attacks by the network, 
see page 25 ("Attacks by networks on other networks"):

https://tools.ietf.org/html/draft-ietf-conex-abstract-mech-13#section-8

Similar as described for the receiver in the TCP mods doc, the network could 
also overstate congestion and cause the sender to send 'unnecessary' marks and 
slow down. But in this case it's really not clear what unnecessary means, as it 
is the networks task to signal congestion... and if the congestion was signaled 
by the network and seen by the audit, the sender has to send the respective 
amount of marks, so it effectively not unnecessary any more. I don't think this 
case makes sense to discuss any further. Is that okay for you?


>
> Thank you.
>
> Take
>