The Tunnel Encapsulations OSPF Router Information
draft-ietf-ospf-encapsulation-cap-09

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.

Alissa Cooper No Record

Warren Kumari No Record

Alexey Melnikov No Record