Hi Adam, Thanks for your review and comments. Please see inline [Bruno]
> From: Adam Roach [mailto:a...@nostrum.com] > Sent: Thursday, August 31, 2017 3:26 AM > > Adam Roach has entered the following ballot position for > draft-ietf-ospf-encapsulation-cap-06: 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-ospf-encapsulation-cap/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 5 specifies that unknown Sub-TLVs are ignored, but that > known-and-invalid Sub-TLVs ruin the whole TLV. [Bruno] "Any unknown Sub-TLVs MUST be ignored and skipped upon receipt." Looks good to me and preserve the TLV properties. "If a Sub-TLV is invalid, its Tunnel Encapsulation TLV MUST be ignored and skipped. However, other Tunnel Encapsulation TLVs MUST be considered." Means that if a tunnel parameter is known to be invalid, the sender has made a syntax or semantic error and the whole tunnel must not be used (as some parameters are known to be wrong, hence the whole tunnel can't be trusted.) I don't see how this behavior ruins the whole TLV. Could you please elaborate? OTOH, I can imagine that the wording is not good enough. I've tried a more detail text: Proposed NEW: Any unknown Tunnel Parameter Sub-Type MUST be ignored and skipped upon receipt. When a reserved value (See <xref target="ParametersRegistry"/>) is seen in an LSA, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. When a Tunnel Parameter Value has an incorrect syntax of semantic, it MUST be treated as an invalid Tunnel Parameter Sub-TLV. If a Tunnel Parameter Sub-TLV is invalid, its Tunnel Sub-TLV MUST be ignored and skipped. However, other Tunnel Sub-TLVs MUST be considered. > It seems a bit odd that a less > capable implementation would be able to act on an announcement of a tunnel, > yet > a more capable one would not -- and that's the exact consequence of this > arrangement. It would seem to make more sense to allow implementations to > ignore invalid Sub-TLVs as if they didn't know them. [Bruno] That's another possible option, but it also has drawbacks. For example the invalid parameter may be a mandatory one (e.g. as the decapsulator, I require encryption) and ignoring this parameter but keeping the tunnel without this parameter may be a policy violation, or lead to technical errors dropping all packets from this tunnel, or sending packet to a wrong destination/tenant if the tunnel is used for overlay.... One option would be to add flags to define the behavior in this case. But that is additional complexity. > Section 7.2 allocates the value 65535 twice (once as "Experimental", once as > "Reserved"). [Bruno] Corrected. Thanks > I believe that this mechanism introduces an attack vector that is not > discussed > in the Security Considerations section. Specifically: because this allows > routers to send OSPF announcements containing arbitrary tunnel termination > addresses, it can cause other routers to attempt to connect to arbitrary > third > parties; [Bruno] I believe this point is already covered (i.e. explicitly forbidden) by the specification: " A tunnel MUST NOT be used if there is no route toward the IP address specified in the Endpoint Sub-TLV or if the route is not advertised by the router advertising the Tunnel Encapsulation attribute for the tunnel." > and, since (by my admittedly shaky understanding of OSPF), I can > distribute this information to a large community of routers with a single > message by sending it to an RR, I can easily cause a *lot* of routers to > potentially send such traffic. For example, if I were able to inject an > announcement that has (a) a tunnel type of 13 ("MPLS in UDP Encapsulation"), > (b) an "Endpoint Sub-TLV" of a victim web server that I know runs QUIC, and > (c) > a "UDP Destination Port" of 443, wouldn't this result in a potential DDoS of > that web server? [Bruno] the text cited specifically forbid this example. > I don't know what the security model of OSPF is or how difficult it would be > to > mount this attack (or even how bad it would be compared to other attacks one > might mount in OSPF), but it seems that a brief treatment of this -- along > with > any operational mitigation techniques that might be employed against it -- > should be part of the Security Considerations. > _________________________________________________________________________________________________________________________ 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. _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
