Re: Éric Vyncke's No Objection on draft-ietf-quic-manageability-16: (with COMMENT)

[Mirja Kuehlewind <[e-mail]>]

Hi Eric,

Thanks for you nice review for this document as well. I filed some issue or directly created some PRs for some of your comments but I still have a few questions. Please see inline.

Mirja
 

On 20.04.22, 08:55, "Éric Vyncke via Datatracker" <[e-mail]> wrote:

    Éric Vyncke has entered the following ballot position for
    draft-ietf-quic-manageability-16: 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/about/groups/iesg/statements/handling-ballot-positions/ 
    for more information about how to handle DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Thank you for the work put into this document.

    Please find below some non-blocking COMMENT points (but replies would be
    appreciated even if only for my own education).

    Special thanks to Matt Joras for the shepherd's write-up including the WG
    consensus and the intended status.

    I hope that this helps to improve the document,

    Regards,

    -éric

    Note for the shepherding AD: missing consensus boilerplate.

    Should there be a section on the usefulness of IPFIX with QUIC ?

    ## Section 2.1

    "All deployed versions are maintained in an IANA registry" is it "deployed" or
    "specified" ? I.e., an operator could always deploy an experimental version not
    yet in the IANA registry.

    The text appears inconsistent to me:

    - "Short headers contain only an optional destination connection ID"

    - "source and destination connection ID: short and long headers carry a
    destination connection ID", i.e., is it optional or not ?

    Also some inconsistency about the spin bit, is it only in v1 or is it an
    invariant ?

    Security ADs will know more of course but for me "cryptographically protected"
    is unclear whether it is confidentiality or integrity or both... Suggest to use
    "is confidentiality/integrity protected with cryptography" (or a lighter
    sentence than this one).

    ## Section 3

    "Here we assume a bidirectional observer", let's also state that there is no
    section about unidirectional observer ?

    ## Section 3.1

    Could the first 1200-byte QUIC packet be used to suspect a QUIC connection
    establishment ?

[MK] Yes, I think if you look at the first packet as a whole you can be reasonably sure that you look at a quic packet. I guess this is an assumption throughout the whole document, as section 2.4 says:

"New QUIC connections are established using a handshake, which is distinguishable on the wire and contains some information that can be passively observed."

[MK] Do we need to say more?

    ## Section 3.7

    Can the data rate in each direction always be used to detect which side is the
    client/initiator vs. server/responder ? Even for HTTP/3 a POST can be larger
    than the reply. Or did I misread this paragraph ?

[MK] Not sure what the intention of this question is. I think this section only says by looking at the data rate you can learn something about symmetry (however, there could also be padding which could conceal the application layer symmetry). Any changes/clarifications needed here?

    ## Section 4.1

    Suggest to expand "CE markings"

    ## Section 4.2

    Thank you for this section, this may be the most useful one :-) (together with
    section 4.9)

    BTW, should there be 2 different time-outs? One for the "connection
    establishment" and one, longer, for "normal traffic".

[MK] The text was written with the assumption of one time-out as  believe usually deployed today. I don't think we want to design anything beyond that in this document.

    ## Section 4.6

    "DDoS" is used while 4.7 use "DDOS" and expand the acronym ;-) (reading the I-D
    as first task in the morning with 2 cups of coffee has some side effects on my
    eyes ;-) )