Re: [Lwip] Benjamin Kaduk's No Objection on draft-ietf-lwig-tcp-constrained-node-networks-11: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Carles,

Thank you for the updates; they look good and I have no further comments.

-Ben

On Fri, Oct 30, 2020 at 09:38:38AM +0100, Carles Gomez Montenegro wrote:
> Hi Benjamin,
> 
> Thank you very much for your review!
> 
> We just submitted revision -12, which aims at addressing the comments
> received from the IESG and related reviewers:
> https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-12
> 
> Please find below our inline responses:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-lwig-tcp-constrained-node-networks-11: 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-lwig-tcp-constrained-node-networks/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Mostly just editorial nits, but please see the comment on Section 5.3.
> >
> > Section 2
> >
> > (I believe the existence of the RFC 8174 version of the BCP 14
> > boilerplate has already been noted.)
> 
> Thanks. In fact, since the document does not use normative language, we 
> removed Section 2 in the last document revision.
> 
> > Section 3.2
> >
> >    or devices with a pool of multiple send/receive buffers.  In the
> >    latter case, it is possible that buffers also be shared for other
> >    protocols.
> >
> > nit: s/be/are/ (or any number of other minor tweaks)
> 
> Done.
> 
> >    One key use case for the use of TCP in CNNs is a model where
> >
> > nit: "use case for the use" is probably redundant: "use case for TCP in
> > CNNs" seems like it would work okay.
> 
> Done, thanks.
> 
> >    middlebox (e.g. a firewall, NAT, etc.).  Figure 1 illustrates such
> >    scenario.  Note that the scenario is asymmetric, as the unconstrained
> >
> > nit: "such a scenario".
> 
> Done.
> 
> > Section 3.3
> >
> >    o  Unidirectional transfers: An IoT device (e.g. a sensor) can send
> >       (repeatedly) updates to the other endpoint.  Not in every case
> >       there is a need for an application response back to the IoT
> >       device.
> >
> > (editorial) I suggest "There is not always a need for an application
> > response back to the IoT device".
> 
> Done.
> 
> > Section 4.1.1
> >
> >    smaller than 1220 bytes (e.g. not larger than 1200 bytes).  Note that
> >    it is advised for TCP implementations to consume payload space
> >    instead of increasing datagram size when including IP or TCP options
> >    in an IP packet to be sent [RFC6691].  Therefore, the suggestion of
> >
> > [my reading of RFC 6691 is that it was required to consume payload
> > space, but only recommended to account for this behavior when
> > advertising MSS.  I guess Erik covered this in his Discuss point already,
> > though.]
> 
> As per a subsequent discussion on the tcpm mailing list, we updated the
> second paragraph of current Section 3.1.1 is as follows:
> 
> NEW:
>    An IPv6 datagram size exceeding 1280 bytes can be avoided by setting
>    the TCP MSS not larger than 1220 bytes.  Note that it is already a
>    requirement that TCP implementations consume payload space instead of
>    increasing datagram size when including IP or TCP options in an IP
>    packet to be sent [RFC6691].  Therefore, it is not required to
>    advertise an MSS smaller than 1220 bytes in order to accommodate TCP
>    options.
> 
> > Section 5.3
> >
> >    The message and latency overhead that stems from using a sequence of
> >    short-lived connections could be reduced by TCP Fast Open (TFO)
> >    [RFC7413], which is an experimental TCP extension, at the expense of
> >    increased implementation complexity and increased TCP Control Block
> >    (TCB) size.  TFO allows data to be carried in SYN (and SYN-ACK)
> >
> > We should probably make at least a passing mention of the TFO security
> > considerations here, possibly with some discussion of why they are less
> > consequential for certain CNNs than in general.  (Note that the security
> > considerations for TFO are not limited to just the risk of replay, and
> > that there are privacy considerations for the TFO cookie being used to
> > link together multiple TCP connections between the same endpoints.)
> 
> We made the following change:
> 
> OLD:
>    The cookie needs to be refreshed (and obtained by the client) after a
>    certain amount of time.  Nevertheless, TFO is more efficient than
>    frequently opening new TCP connections with the traditional three-way
>    handshake, as long as the cookie can be reused in subsequent
>    connections.
> 
> NEW:
>    The cookie needs to be refreshed (and obtained by the client) after a
>    certain amount of time.  While a given cookie is used for multiple
>    connections between the same two endpoints, the latter may become
>    vulnerable to privacy threats.  In addition, a valid cookie may be
>    stolen from a compromised host and may be used to perform SYN flood
>    attacks, as well as amplified reflection attacks to victim hosts (see
>    Section 5 of RFC 7413).  Nevertheless, TFO is more efficient than
>    frequently opening new TCP connections with the traditional three-way
>    handshake, as long as the cookie can be reused in subsequent
>    connections.
> 
> > Section 10.1
> >
> > RFC 3819 may not need to be listed as normative, given the nature of the
> > one place in which it is referenced.
> >
> > Similarly, we don't say much about TCP-AP other than it exists, so RFC
> > 5925 may not need to be normative either.
> 
> Done!
> 
> > Section 10.2
> >
> > RFC 6092 appears to not be referenced from anywhere?
> 
> We removed the reference (it was used in some older version of the draft).
> 
> > idnits notes a couple other reference-related issues.
> 
> We believe that we cleared those as well in -12.
> 
> Thanks,
> 
> Carles (on behalf of the authors)
>