Re: [Dots] Éric Vyncke's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT)

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

Re-re-bonjour Med,

Thank you for your prompt reply, all your replies are good for me 

Regards

-éric

-----Original Message-----
From: "[e-mail]" <[e-mail]>
Date: Monday, 14 December 2020 at 15:12
To: Eric Vyncke <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Valery Smyslov <[e-mail]>
Subject: RE: Éric Vyncke's No Objection on draft-ietf-dots-signal-call-home-11: (with COMMENT)

    Re-bonjour Eric, 

    Thank you for the review. 

    Please see inline.

    Cheers,
    Med

    > -----Message d'origine-----
    > De : Éric Vyncke via Datatracker [mailto:[e-mail]]
    > Envoyé : lundi 14 décembre 2020 11:41
    > À : The IESG <[e-mail]>
    > Cc : [e-mail]; dots-
    > [e-mail]; [e-mail]; Valery Smyslov <[e-mail]>;
    > [e-mail]
    > Objet : Éric Vyncke's No Objection on draft-ietf-dots-signal-call-
    > home-11: (with COMMENT)
    > 
    > Éric Vyncke has entered the following ballot position for
    > draft-ietf-dots-signal-call-home-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-dots-signal-call-home/
    > 
    > 
    > 
    > --------------------------------------------------------------------
    > --
    > COMMENT:
    > --------------------------------------------------------------------
    > --
    > 
    > Thank you for the work put into this document. Congratulations for
    > the many nice ASCII artworks ;-) Using the SVG alternate artwork
    > could have even been nicer ;-)
    > 
    > Please find below  some non-blocking COMMENT points (but replies
    > would be appreciated), and some nits.
    > 
    > I will let the transport AD to decide on the IANA point.

    [Med] FWIW, the rationale for the request can be found at: https://mailarchive.ietf.org/arch/msg/dots/GQP-QCmC-4XtJHPmsPR_quuyO0c/ 

    > 
    > I hope that this helps to improve the document,
    > 
    > Regards,
    > 
    > -éric
    > 
    > == COMMENTS ==
    > -- Abstract --
    > I wonder whether the 2nd paragraph is really useful.

    [Med] We added that text to address a comment we received in the past: the "call home" was misinterpreted as if this is specific to home networks. I suggest to maintain this sentence. Thanks.

    > 
    > -- Section 1.1 --
    > Should the DOTS acronym be expanded before first use ?

    [Med] Done. Please see https://tinyurl.com/dots-call-home-latest 

    > 
    > Please add a reference to "Slowloris"

    [Med] Sure. Please see the diff.   

    > 
    > Did the authors/WG consider mentioning MUD in this lengthy
    > discussion about IoT @ Home ?

    [Med] We do cite RFC8576, which discusses MUD. Not sure there is a value in citing it here.   

    > 
    > -- Section 5.2.1 --
    > "When an outgoing attack that saturates the outgoing link", but,
    > what about an "incoming attack" ?

    [Med] That one is covered by the following two paragraphs. The fact that the loss is due to an incoming attack is not used for session management purposes. The DOTS Call Home Server does not have the visibility on the incoming attacks (see the reference architecture); that is visible to a DOTS client (base signal channel), if any. 

    > 
    > -- Section 5.2.2 --
    > Thank you for using an IPv6-only example !
    > 
    > -- Section 5.3.1 --
    > Can source-prefix be a link-local address (normally not forwarded by
    > a router but what if the CPE is a layer-2 node) ?

    [Med] Private (for IPv4), link-local, or ULAs are not forbidden. Only loopback, broadcast, and multicast addresses are not allowed.

    > 
    > In figure 9, while "2001:db8:123::/128" is a valid node address but
    > it looks like a prefix, may I suggest to use "2001:db8:123::1/128"
    > that better suggest a host address ?

    [Med] No problem. See the diff. 

    > 
    > -- Section 5.3.2 --
    > Congratulations to the authors for describing the NAT64/MAP
    > behaviors.
    > 
    > -- Section 8 --
    > "The DOTS Call Home can be misused " should probably include
    > "server".
    > 

    [Med] As you can see in the diff, changed to "The DOTS Call Home signal channel can be misused".

    > -- Section 9 --
    > How is the privacy among DOTS servers enforced ? E.g., how can the
    > DOTS client only send mitigation information about subscriber A
    > prefix(es) and not subscriber B prefix(es)? There could obviously be
    > a link to RADIUS and DHCP servers but I did not read anything about
    > this. Or is 'common sense' / implicit ?

    [Med] We focus on the external behavior: 

          the Call Home DOTS client MUST validate that attacker
          prefixes are within the scope of the Call Home DOTS server domain
          (e.g., prefixes assigned to the Call Home DOTS server domain or
          networks it services).

    How this is enforced is deployment-specific. 

    Do you prefer to see DHCP/RADIUS cited? 

    > 
    > == NITS ==
    > 
    > s/Figure 10 depictes/Figure 10 depicts/

    [Med] Fixed. Thanks.


    _________________________________________________________________________________________________________________________

    Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
    pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
    a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
    Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

    This message and its attachments may contain confidential or privileged information that may be protected by law;
    they should not be distributed, used or copied without authorisation.
    If you have received this email in error, please notify the sender and delete this message and its attachments.
    As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
    Thank you.