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

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 26 Aug 2015 12:05:20 +0900

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

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 26 Aug 2015 11:49:47 +0200

Hi Take,

thanks for you feedback!

See below.

Mirja

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

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

> increase the likelihood of loss at an audit function?

No.

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

> security considerations are covered extensively in the ConEx abstract

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?

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 26 Aug 2015 19:35:59 +0900

Hi Mirja,

> > I can understand that "the sender can choose to mark inaccurately,
> > which will only increase the likelihood of loss at an audit function."
> 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.

I got it.
(Until I read your email, I thought you were talking about a malicious
sender who intentionally marks inaccurately.)
This makes sense to me.

> > Or, if the sender marks more than actual congestion states, does that
> > also increase the likelihood of loss at an audit function?
> 
> No.
> 
> >
> 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.

I agree. I thought you wanted to mention this in the section, though it is
totally up to you and I do not stick to that at all.
Indeed, you clearly mentioned that ConEx specific security issues are
considered in the other draft.
(Likewise, I thought you also wanted to mention that TCP-specific security
issues are still issues here.)

I do not have any further comments.
This was a fun to read the draft.

Thank you for the work.

Kind regards,
Take

> -----Original Message-----
> From: Mirja Kühlewind [mailto:[email-masked]]
> Sent: Wednesday, August 26, 2015 6:50 PM
> To: Takeshi Takahashi;
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Secdir review of draft-ietf-conex-tcp-modifications-09
> 
> Hi Take,
> 
> thanks for you feedback!
> 
> See below.
> 
> Mirja
> 
> > 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 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.
> > This document thus considers assorted cases of receivers' protocol
> > support status and provides the solution (or guideline) to use ConEx
with
> TCP.
> > 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."
> 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.
> 
> > Or, if the sender marks more than actual congestion states, does that
> > also increase the likelihood of loss at an audit function?
> 
> No.
> 
> >
> I don't think there is an additional risk of actual hijacking (compared to
> TCP without ConEx).
> > Or should I think that this issue is covered by the sentence "General
> > Conex security considerations are covered extensively in the ConEx
> > abstract mechanism"?
> 
> 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
> >