Re: [Int-dir] Éric Vyncke's Discuss on draft-ietf-taps-transport-security-11: (with DISCUSS and COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Magnus

A simple mention of the lack of IPv6 in section 3 of the description would be more than enough for me.

-éric

-----Original Message-----
From: iesg <[e-mail]> on behalf of Magnus Westerlund <magnus.westerlund=[e-mail]>
Date: Thursday, 9 April 2020 at 14:16
To: "[e-mail]" <[e-mail]>, Eric Vyncke <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Mohit Sethi M <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-taps-transport-security-11: (with DISCUSS and COMMENT)

    Hi Eric,
    
    Aren't you going a bit to far now with this discuss? Yes, IETF stream
    procotocols are expected to support IPv6. This is a non-IETF devleoped security
    protocol which is investigated from the perspective of its features to influence
    considerations of required API surface for security features. All discussed in
    relation to a set of aspects where the only one having to do with addressing is
    source-address valdiation and which CurveCP do not support as particular
    relevant. 
    
    I don't see how it is going to affect or impact that future work in TAPS WG..
    
    Why do you think an aspect of a protocol that isn't discussed being relevant to
    mention? 
    
    If you have a good reason fine then a disclaimer could be added. But I don't see
    how it would not result in a unconnected comment on a specific protocol which
    has no connection to the purpose of the document.
    
    Cheers
    
    Magnus
    
    
    
    On Thu, 2020-04-09 at 03:01 -0700, Éric Vyncke via Datatracker wrote:
    > Éric Vyncke has entered the following ballot position for
    > draft-ietf-taps-transport-security-11: Discuss
    > 
    > 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-taps-transport-security/
    > 
    > 
    > 
    > ----------------------------------------------------------------------
    > DISCUSS:
    > ----------------------------------------------------------------------
    > 
    > Thank you for the work put into this document. It is really easy to read.
    > 
    > Nevertheless, I am balloting a DISCUSS (see below), I sincerely hope that I am
    > wrongly asserting the lack of IPv6 support for CurveCP else the easy way to
    > clear my DISCUSS would be to mention this limitation in section 3 even if the
    > focus of this I-D is on the API.
    > 
    > Please find below some non-blocking COMMENTs. An answer will be appreciated.
    > 
    > I hope that this helps to improve the document,
    > 
    > Regards,
    > 
    > -éric
    > 
    > == DISCUSS ==
    > 
    > I question the inclusion of CurveCP in the mix as per
    > 
    https://protect2.fireeye.com/v1/url?k=c6d9b121-9a0dbd7f-c6d9f1ba-8691959ed9b7-6efcfea6e017deb9&q=1&e=d62bfe3e-4eac-4ef1-877e-ac1f40b4418d&u=https%3A%2F%2Fcurvecp.org%2Faddressing.html
    >  it does not seem to support IPv6. At the
    > bare minimum, the I-D should mention this restriction in section 3. (and I
    > hope
    > to be corrected about CurveCP IPv6 support).
    > 
    > 
    > ----------------------------------------------------------------------
    > COMMENT:
    > ----------------------------------------------------------------------
    > 
    > Please respond to the IoT-directorate review by Mohit:
    > 
    https://mailarchive.ietf.org/arch/msg/iot-directorate/xTVOvQ7kI78sDPZQuVsTvGB2x0s
    > Please respond to the INT-DIR review by Brian:
    > https://mailarchive.ietf.org/arch/msg/int-dir/2IHPgukaAAMvMjO7TXvo_ujcI_I +
    > Gorry Fairhurst's about GRE
    > 
    > Generic comment about the intended transport: all protocols analyzed in this
    > document are point to point (no multicast), this should probably be mentioned
    > in the introduction.
    > 
    > -- Section 1 --
    > Is there any reason why the integrity property of IPsec AH is not mentioned ?
    > Same also applies in section 2 when "security protocol" is defined.
    > 
    > -- Section 3 --
    > Use the wording of "record protocol" generically while the term "record
    > protocol" is defined in section 2 as a blocked data transport (like in TLS).
    > Suggest the use of "data transfer protocol" ?
    > 
    > An important property of such protocols is to be able to traverse a NAPT box
    > (that I hate)... I suggest to mention whether the analyzed protocols support
    > NAT-traversal in this description section or even in the analysis parts as
    > having a different view (application and network layers seeing possibly
    > different IP addresses so a potential impact on the API).
    > 
    > 
    > 
    -- 
    Cheers
    
    Magnus Westerlund 
    
    
    ----------------------------------------------------------------------
    Networks, Ericsson Research
    ----------------------------------------------------------------------
    Ericsson AB                 | Phone  [phone]
    Torshamnsgatan 23           | Mobile [phone]
    SE-164 80 Stockholm, Sweden | mailto: [e-mail]
    ----------------------------------------------------------------------