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