The Tunnel Encapsulations OSPF Router Information
Summary: Has enough positions to pass.
Alia Atlas Yes
Deborah Brungard No Objection
Ben Campbell No Objection
Comment (2017-08-29 for -06)
I agree with Mirja's comment concerning the IANA considerations.
Benoit Claise (was Discuss) No Objection
Comment (2017-09-23 for -08)
Trusting the group, doc. shepherd and responsible AD that the right things will happen.
Spencer Dawkins No Objection
Comment (2017-08-27 for -06)
It surprised me to learn that this capability wasn't already in OSPF! Thanks for doing the work.
Suresh Krishnan (was Discuss) No Objection
Comment (2017-09-18 for -08)
Thanks for addressing my DISCUSS and COMMENT points
Mirja Kühlewind No Objection
Comment (2017-08-28 for -06)
I agree with the gen-art review (Thanks Pete!) that the new registry should point to the RFCs that define the actually Sub-TLV (behavior). I would simply recommend to reference both RFCs, this document and the respective other RFC/draft that defines the details.
Terry Manderson No Objection
Kathleen Moriarty No Objection
Eric Rescorla No Objection
Alvaro Retana No Objection
Comment (2017-08-30 for -06)
I think there's a normative conflict in these two pieces of text; the first one from Section 3, and the second from Section 5: ...If the Encapsulation Capability TLV appears more than once in an OSPF Router Information LSA, only the first occurrence MUST be processed and others MUST be ignored. ... Any unknown Sub-TLVs MUST be ignored and skipped upon receipt. If a Sub-TLV is invalid, its Tunnel Encapsulation TLV MUST be ignored and skipped. However, other Tunnel Encapsulation TLVs MUST be considered. The text from Section 3 says that only the first TLV [*] is to be processed -- but during such processing the receiver may find an invalid sub-TLV, which then mandates (in Section 5) for other TLVs to be considered. I think that the easy solution is to change the second "MUST" from Section 3 for a "SHOULD". It would be nice to describe what is an "invalid" sub-TLV, and that "invalid" is not the same as "unknown" (right?)...but that an "unknown [tunnel] types are to be ignored and skipped upon receipt", which would result in processing the second (if any) TLV. [*] Benoit's ballot pointed at the need for consistency in the names.
Adam Roach No Objection
Comment (2017-08-30 for -06)
Section 5 specifies that unknown Sub-TLVs are ignored, but that known-and-invalid Sub-TLVs ruin the whole TLV. 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. Section 7.2 allocates the value 65535 twice (once as "Experimental", once as "Reserved"). 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; 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? 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.