Skip to main content

OSPF Advertisement of Tunnel Encapsulations
draft-ietf-ospf-encapsulation-cap-09

Yes

(Alia Atlas)

No Objection

(Deborah Brungard)
(Eric Rescorla)
(Kathleen Moriarty)
(Terry Manderson)

Note: This ballot was opened for revision 06 and is now closed.

Alia Atlas Former IESG member
Yes
Yes (for -06) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (2017-08-30 for -06) Unknown
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.
Alvaro Retana Former IESG member
No Objection
No Objection (2017-08-30 for -06) Unknown
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.
Ben Campbell Former IESG member
No Objection
No Objection (2017-08-29 for -06) Unknown
I agree with Mirja's comment concerning the IANA considerations.
Benoît Claise Former IESG member
(was Discuss) No Objection
No Objection (2017-09-23 for -08) Unknown
Trusting the group, doc. shepherd and responsible AD that the right things will happen.
Deborah Brungard Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (for -06) Unknown

                            
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-08-28 for -06) Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection (2017-08-27 for -06) Unknown
It surprised me to learn that this capability wasn't already in OSPF! Thanks for doing the work.
Suresh Krishnan Former IESG member
(was Discuss) No Objection
No Objection (2017-09-18 for -08) Unknown
Thanks for addressing my DISCUSS and COMMENT points
Terry Manderson Former IESG member
No Objection
No Objection (for -06) Unknown