Subject: Re: [tsvwg] Mirja Kühlewind's No Objection on draft-ietf-tsvwg-ecn-experimentation-06: (with COMMENT)

From: "Black, David" <[email-masked]>
Date: Tue, 17 Oct 2017 19:44:15 +0000

Mirja,

Thanks for the careful review, comments inline ... and I'll work on specific text for this concern:

>  I suggest we say something simpler like ECT(1) is reserved for use by
> TSVWG. (This will be used by L4S, until this experiment is concluded or this
> allocation is made permanent).

directly with you, Gorry and Spencer.

Thanks, --David

> -----Original Message-----
> From: Gorry (erg) [mailto:[email-masked]]
> Sent: Wednesday, September 27, 2017 3:14 AM
> To: Mirja Kühlewind <[email-masked]>
> Cc: The IESG <[email-masked]>; draft-ietf-tsvwg-ecn-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] Mirja Kühlewind's No Objection on draft-ietf-tsvwg-ecn-
> experimentation-06: (with COMMENT)
> 
> Mirja, thanks for the review. I was document shepherd and have some
> observations.
> 
> > On 26 Sep 2017, at 20:41, Mirja Kühlewind <[email-masked]> wrote:
> >
> > Mirja Kühlewind has entered the following ballot position for
> > draft-ietf-tsvwg-ecn-experimentation-06: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > 1) section 2 actually seems a bit redundant to me but I guess that not a
> > problem. I guess I would also be okay with the doc if section 2 would not be
> > there, but maybe this overview actually helps others who are less familiar
> with
> > ECN.
> >
[David>] Including at least one other AD ;-). I think this section stays in.

> > 2) I guess it could actually be helpful to include a tiny bit of reasoning why
> > the ECN Nonce experiment is concluded instead of just saying that it was never
> > deployed and further point to an appendix of a draft (which is actually
> > appendix C and not B.1 I believe). I know this was discussed, but having one
> > sentence saying something in the lines like this is probably not to hard: "The
> > experiment is concludes with the result that ECN Nonce does not provide a
> > reliable integrity protection as the other end can always pretend to not
> > support this optional feature."
> 
> That argument was presented along with others - although I suggest this is
> not really a new argument.
> 
> There is value in a protection mechanism in a transport protocol, and had the
> nonce mechanism been deployed, senders could require this when using
> ECN - or could alternatively have opted for some other fallback method,
> knowing the receiver would not honour the nonce. I do not think this extra
> sentence is correct, nor important - the unusuability was a consequence of
> non deployment.
> 
[David>] I concur with Gorry that non-deployment is the main reason, so the current text suffices.

> > 3) This sentence is a bit unclear:
> > "In addition, until the conclusion of the L4S experiment, use of
> >   ECT(1) in IETF RFCs is not appropriate, as the IETF may decide to
> >   allocate ECT(1) exclusively for L4S usage if the L4S experiment is successful."
> > I guess the L4S exp RFC would use ECT(1), so the sentence to not really make
> > sense to me.
> I see this issue. The bashed text does seem too contorted!
> 
>  I suggest we say something simpler like ECT(1) is reserved for use by
> TSVWG. (This will be used by L4S, until this experiment is concluded or this
> allocation is made permanent).
> 
> > Also given that there is no RFC for L4S yet, we actually don't
> > know if there is finally community/group consensus to publish that RFC. I
> guess
> > it actually to early to say something like this. I know why you want to have
> > this sentence in there, but from the processing point of view that does not
> > seems to be the correct thing to do and it might be better to just remove it.
> > Otherwise, if you want to  keep it or something similar but maybe less
> > specific, following up on the feedback provided by IANA, the TCP flag should
> > probably be just marked as reserved with reference to this RFC.
> >
> I think reserving ECT(1) for this RFC could make sense.
> 
[David>] I'll follow up directly with you and Gorry to carefully craft some text to reserve further use of ECT(1) to TSVWG.  As indicated in my response to Benoit's Discuss, I want to avoid any implication that a change to the IANA registration of ECT(1) is needed at this time.

> > 4) I'm not certain about this part:
> > "An exception to this requirement occurs in
> >      responding to an ongoing attack.  For example, as part of the
> >      response, it may be appropriate to drop more ECT-marked TCP SYN
> >      packets than TCP SYN packets marked with not-ECT. "
> > Maybe it's to late here and that's the reason I don't get it, but what would be
> > the reason to rather drop ETC marked SYNs? Can you explain?

[David>] The explanation is that the attacker may be using ECN to try to avoid network drops, thereby increasing the (over)load on the target - which is implied at the end of that paragraph: "SHOULD only be done if it is determined that the ECT capability is contributing to the attack." I've edited the text in my working version to:

	An exception to this requirement occurs in responding to an attack that uses ECN codepoints
	other than Not-ECT. For example, as part of the response, it may be appropriate to drop ECT-marked
	TCP SYN packets with higher probability than TCP SYN packets marked with not-ECT. Any such
	exceptional discarding of TCP control packets and retransmitted TCP packets in response to an
	attack MUST NOT be done routinely in the absence of an attack and SHOULD only be done
	if it is determined that the use of ECN is contributing to the attack.

> > I do understand
> > that there is no reason to not drop ECT-marked SYNs in an attack situation
> > (meaning don't try to mark, drop immediately) but I don't understand why you
> > should drop ECT-marked SYNs preferentially? If the assumption is that attacker
> > would more likely use ECN than non-attackers because the will usually not be
> > dropped but marked, I'm uncertain if that is true and still not sure if the
> > above recommendation is appropriate. In any case I think this needs at least
> > more explanation in the document.
> >
> I suggest SYN attacks need to be considered - and I would like to see that
> noted here - however, stating what reaction is needed in this case, should be
> the subject of the TCPM ID.
> 
[David>] I tried to stay on the right side of this concern by couching the TCP SYN attack material as an example.

> > 5) As a side note on this sentence:
> > "Random ECT values MUST NOT be used, as that may expose RTP to
> >      differences in network treatment of traffic marked with ECT(1) and
> >      ECT(0) and differences in associated endpoint congestion
> >      responses, e.g., as proposed in [I-D.ietf-tsvwg-ecn-l4s-id]."
> > I think random marking is anyway not a good idea because this is sometimes used
> > (incorrectly) as input for ECMP. Therefore I actually think the reference to
> > the l4s draft is actually not needed here.
> >
> 
[David>] RFC 6679 supports random ECT values - see first chunk of text quoted from that RFC.  Outright prohibition of them risks breaking running code, as there is negotiation support specified for them in RFC 6679.  I've removed the reference to the L4S draft.