Last Call Review of draft-ietf-conex-tcp-modifications-09
review-ietf-conex-tcp-modifications-09-secdir-lc-takahashi-2015-08-26-00

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

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.

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

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:mirja.kuehlewind

 at tik.ee.ethz.ch]
> Sent: Wednesday, August 26, 2015 6:50 PM
> To: Takeshi Takahashi;
> draft-ietf-conex-tcp-modifications.all at tools.ietf.org
> Cc: iesg at ietf.org; secdir at ietf.org; conex-chairs at tools.ietf.org
> Subject: Re: Secdir review of draft-ietf-conex-tcp-modifications-09
> 
> 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
> >