[OSPF] Adam Roach's No Objection on draft-ietf-ospf-encapsulation-cap-06: (with COMMENT)

[Adam Roach <[e-mail]>]

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. 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.