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

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

Alvaro Retana No Objection

Comment (2017-08-30 for -06)
No email
send info
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.

(Alia Atlas; former steering group member) Yes

Yes ( for -06)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection (2017-08-30 for -06)
No email
send info
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.

(Ben Campbell; former steering group member) No Objection

No Objection (2017-08-29 for -06)
No email
send info
I agree with Mirja's comment concerning the IANA considerations.

(Benoît Claise; former steering group member) (was Discuss) No Objection

No Objection (2017-09-23 for -08)
No email
send info
Trusting the group, doc. shepherd and responsible AD that the right things will happen.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Eric Rescorla; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Kathleen Moriarty; former steering group member) No Objection

No Objection ( for -06)
No email
send info

(Mirja Kühlewind; former steering group member) No Objection

No Objection (2017-08-28 for -06)
No email
send info
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 steering group member) No Objection

No Objection (2017-08-27 for -06)
No email
send info
It surprised me to learn that this capability wasn't already in OSPF! Thanks for doing the work.

(Suresh Krishnan; former steering group member) (was Discuss) No Objection

No Objection (2017-09-18 for -08)
No email
send info
Thanks for addressing my DISCUSS and COMMENT points

(Terry Manderson; former steering group member) No Objection

No Objection ( for -06)
No email
send info