Hi Dave, Thank you for the review. Please see inline. Cheers, Med > -----Message d'origine----- > De : Dave Thaler via Datatracker <noreply@xxxxxxxx> > Envoyé : mercredi 27 avril 2022 01:27 > À : int-dir@xxxxxxxx > Cc : dots@xxxxxxxx; draft-ietf-dots-multihoming.all@xxxxxxxx; > last-call@xxxxxxxx > Objet : Intdir telechat review of draft-ietf-dots-multihoming-12 > > Reviewer: Dave Thaler > Review result: Ready with Issues > > I am an assigned INT directorate reviewer for draft-ietf-dots- > multihoming-12. These comments were written primarily for the > benefit of the Internet Area Directors. Document editors and > shepherd(s) should treat these comments just like they would treat > comments from any other IETF contributors and resolve them along > with any other Last Call comments that have been received. For > more details on the INT Directorate, see > https://datatracker.ietf.org/group/intdir/about/ > > Technical comments potentially worth a discuss: > * Section 4.2: multiple PVDs is not synonymous with distinct > administrative entities, > as evidenced by section 4.1, so would recommend: > OLD: That router is connected to multiple provisioning domains > (i.e., > OLD: managed by distinct administrative entities). > NEW: That router is connected to multiple provisioning domains > NEW: managed by distinct administrative entities. [Med] Fully agree. Fixed. > > * Section 5.2: > > when PI addresses/prefixes are assigned and absent any policy, > the > > client-domain DOTS gateway MUST send mitigation requests to all > its > > DOTS servers. Otherwise, the attack traffic may still be > delivered > > via the ISP which hasn't received the mitigation request. > > If RPF checks are applied by policy to all inbound traffic, then I > think the attack could only come via a PVD that advertises to the > client domain prefixes covering the attack sources. In that case > the MUST might be too strong if no attack is coming from one of > the PVDs (e.g., an IPv6-only PVD). Do we really want to require > sending it to such networks? [Med] The attack traffic is bound to a target resource that is reachable via all available paths with the same IP address. The default behavior is to proactively seek for mitigation independent of the initial path that was used to receive the attack traffic and not wait till all available pipes are saturated. Please note that a large set of sources can be involved in an attack. Specific cases are handled by policy and will fall under the policy mentioned in the first sentence: " when PI addresses/prefixes are assigned and absent any policy". After re-reading the text, the current "MUST ...except .." is actually a SHOULD. Updated the text accordingly. > > Section 5.2: > > The use of anycast > > addresses to reach these DOTS servers is NOT RECOMMENDED. If a > well- > > known anycast address is used to reach multiple DOTS servers, > the CPE > > may not be able to select the appropriate provisioning domain to > which > > the mitigation request should be forwarded. As a consequence, > the > > request may not be forwarded to the appropriate DOTS server. > > If each PVD uses a different anycast address for their own DOTS > servers, is there still a problem? If so, can the document explain > what is the problem? The current text only seems to explain the > case when the same anycast address is used by different PVDs but > the statement above about NOT RECOMMENDED is not currently > constrained to that case. > [Med] Fair point. Changed to "The use of the same anycast addresses ..." > * Section 5.3: > > Note that anycast addresses cannot be > > used to establish DOTS sessions between DOTS clients and client- > > domain DOTS gateways because only one DOTS gateway will receive > the > > mitigation request. > > I wonder if this is too strongly worded. I suspect you mean that > G1 and G2 cannot use the same anycast address. [Med] Yes. But if G1 and G1' > both use the same anycast address for redundancy in that > topological location, is there a problem? [Med] Yes: only one mitigation server will be solicited while the attack traffic may still be forwarded over the other paths. It is even worse when the attack is more severe over the other paths for which no mitigation was requested. In contrast, I observe > that the last paragraph of this section says only "NOT > RECOMMENDED", not "MUST NOT". > [Med] That text for PA, not PI. > Editorial nits: [Med] Good catches. Fixed. Thanks. > * Section 3: in the two definitions, either remove "are" after the > colon > or remove the colon so they're either sentences or definitions, > not a weird mix. > * Section 3: re "Provider-Independent (PI) addresses: are > globally-unique addresses > which are not assigned by a transit provider". Change "which" > to "that" > per Chicago Manual of Style ("which" and "that" have the same > meaning in > British English but slightly different meanings in American > English) > * Section 5.1: "DOTS signaling session to a given DOTS server must > be established > using the interface from which the DOTS server was provisioned." > Grammar: > insert "A" at the start of the sentence > * Section 5.2: typo "One of more DOTS clients", s/of/or/ > * Section 5.2: s/an unicast/a unicast/ > * Section 5.2: "the attack traffic may still be delivered via the > ISP which > hasn't received the mitigation request", s/which/that/ > > Dave Thaler > > _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
