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

Received changes through RFC Editor sync (created alias RFC 9013, changed title to 'OSPF Advertisement of Tunnel Encapsulations', changed abstract to 'Networks use tunnels for a variety of reasons.  A large variety of tunnel types are defined, and the tunnel encapsulator router needs to select a type of tunnel that is supported by the tunnel decapsulator router.  This document defines how to advertise, in OSPF Router Information Link State Advertisements (LSAs), the list of tunnel encapsulations supported by the tunnel decapsulator.', changed pages to 10, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2021-04-27, changed IESG state to RFC Published)

[Ballot discuss]
* There seems to be an difference between this document's definition of sub-TLVs (with 2 octet types and lengths) and those of RFC5512 (with 1 octet types and lengths). So I am surprised to see the document point to the RFC5512 based TLVs for both syntax and semantics (Sections 5.1, 5.2, 5.3 ...) . Can you please explain how these sub-TLVs are encoded on the wire to be compatible with this draft?

[Ballot comment]
* IANA considerations

Looks like the value 65535 is included both as experimental and reserved. Suggest changing

OLD:
65500-65535    Experimental                              This document

NEW:
65500-65534    Experimental                              This document

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

[Ballot comment]
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.

[Ballot discuss]
1. I agree with Tim Wicinski's OPS DIR point about IANA.

    The content appears to be fine, but there are some outdated (the biggest one is
    5226 replaced by 8126), but its the IANA section which appears the most
    confusing.

    7.1 OSPF Router Information (RI) Registry -  appears fine

    7.2 OSPF Tunnel Encapsulation Attribute Sub-TLV Registry

    This one defines the values being defined/allocated from "This Document" but in
    Section 5, each Sub-TLV is defined in other documents, so it's totally
    confusing.

2. It's not clear which of the following sub-TLVs are required/relevant/interconnected in the Encapsulation Capability TLV

            0    Reserved                                  This document
            1    Encapsulation                            This document
            2    Protocol Type                            This document
            3    Endpoint                                  This document
            4    Color                                    This document
            5    Load-Balancing Block                      This document
            6    IP QoS                                    This document
            7    UDP Destination Port                      This document

The only hint is:

      Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
      TLVs as defined in Section 5.

Zero? really, what's the point?
Now, from an operational point of view, which sub-TLVs are required/make sense?
Are some sub-TLVs irrelevant without others? Ex: Color without Encapsulation
Could we have multiple identical sub-TLVs? Ex: Color

[Ballot comment]
- Sometimes you use "Encapsulation Capability TLV" (section 3), sometimes "The Tunnel Encapsulation Type Sub-TLV"
I guess that:
OLD:

The Tunnel Encapsulation Type Sub-TLV is structured as follows:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Tunnel Type (2 Octets)    |        Length (2 Octets)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                              |
      |                            Sub-TLVs                          |
      |                                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


NEW:
The Encapsulation Capability TLV is structured as follows:

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Tunnel Type (2 Octets)    |        Length (2 Octets)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                              |
      |                            Sub-TLVs                          |
      |                                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In section 7.1, should it be?
OLD:
    Value  TLV Name                                  Reference
      -----  ------------------------------------  -------------
      TBD1    Tunnel Capabilities                    This document

NEW:
    Value  TLV Name                                  Reference
      -----  ------------------------------------  -------------
      TBD1    Encapsulation Capabilities            This document

OR:
    Value  TLV Name                                  Reference
      -----  ------------------------------------  -------------
      TBD1    Tunnel Encapsulation Capabilities      This document


- Then there is a discrepancy between Sub-TLVs and Value in the related text

      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Tunnel Type (2 Octets)    |        Length (2 Octets)      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                              |
      |                            Sub-TLVs                          |
      |                                                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Proposal: Sub-TLVs should be replaced by "Tunnel Encapsulation Attribute Sub-TLVs", and the following text updated:

  Value (variable): Zero or more Tunnel Encapsulation Attribute Sub-
      TLVs as defined in Section 5.

- Then, reading section 5, I see yet another name: "OSPF Tunnel Encapsulation Attribute Sub-TLVs" Section 7.2.

You should re-read the document to be consistent with your naming convention, in the text and in the IANA sections.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-ospf-encapsulation-cap-06. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

Note: We sent the following question to the authors --> We understand that reservations about the requests made in the IANA Considerations section of this draft have been raised in the GENART review. We would like to know how the authors intend to resolve those comments before providing a formal review for IESG Last Call.

The IANA Services Operator understands that, upon approval of this document, the current draft of the document has two actions which we must complete.

First, in the OSPF Router Information (RI) TLVs registry on the Open Shortest Path First (OSPF) Parameters registry page located at:

https://www.iana.org/assignments/ospf-parameters/

a single, new TLV will be registered as follows:

Value: [ TBD-at-registration ]
TLV Name: Tunnel Capabilities
Reference: [ RFC-to-be ]

Second, a new registry is to be created called the OSPF Tunnel Encapsulation Attribute Sub-TLVs registry.

IANA QUESTION -> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The registration rules for the new registry are as follows:

The values in the range 1-255 are to be allocated using the "Standards Action" registration procedure as defined in [RFC8126].

The values in the range 256-65499 are to be allocated using the "First Come, First Served" registration procedure.

There are initial registrations in the new registry as follows:

Value Name Reference
----------- --------------------- -------------
0 Reserved [ RFC-to-be ]
1 Encapsulation [ RFC-to-be ]
2 Protocol Type [ RFC-to-be ]
3 Endpoint [ RFC-to-be ]
4 Color [ RFC-to-be ]
5 Load-Balancing Block [ RFC-to-be ]
6 IP QoS [ RFC-to-be ]
7 UDP Destination Port [ RFC-to-be ]
8-65499 Unassigned
65500-65535 Experimental [ RFC-to-be ]
65535 Reserved [ RFC-to-be ]

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.


Thank you,

Sabrina Tanamal
IANA Services Specialist

[Ballot comment]
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.

The following Last Call announcement was sent out (ends 2017-08-28):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ospf-encapsulation-cap@ietf.org, ospf@ietf.org, Acee Lindem , akatlas@gmail.com, acee@cisco.com, ospf-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Advertising Tunneling Capability in OSPF) to Proposed Standard


The IESG has received a request from the Open Shortest Path First IGP WG
(ospf) to consider the following document: - 'Advertising Tunneling
Capability in OSPF'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-08-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Networks use tunnels for a variety of reasons.  A large variety of
  tunnel types are defined and the ingress needs to select a type of
  tunnel which is supported by the egress and itself.  This document
  defines how to advertise egress tunnel capabilities in OSPF Router
  Information Link State Advertisement (LSAs).





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ospf-encapsulation-cap/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-idr-tunnel-encaps: The BGP Tunnel Encapsulation Attribute (None - IETF stream)

As is customary, I have done my AD review of draft-ietf-ospf-encapsulation-cap-03.
First, I would like to thank the authors - Xiaohu, Bruno, Robert, Luis, and Luay - for their work on this useful document.

I do have a few concerns that need addressing before the draft can progress.

Major:

1) First, the draft talks about what information is sent - but nothing about how it is to be understood or used.  That'd be ok if there were a clear reference to a document that discussed the related procedures.  A quick scan of draft-ietf-idr-tunnel-encaps-06 seems that it may be the right place to start - but it's procedures are BGP-focused and while there are many similarities, there may be interesting differences as well. 
For instance, for the Color sub-TLV, is the 4 byte color value expected to represent the same meaning in OSPF as in BGP?  Can a BGP route with a particular color extended community then have the OSPF tunnel to use selected from only those tunnels with the same color?  What does the Color TLV mean in a purely OSPF context?  Sec 7 of draft-ietf-idr-tunnel-encaps-06 ("However, suppose that one of the TLVs in U2's Tunnel Encapsulation attribute contains the Color Sub-TLV.  In that case, packet P SHOULD
  NOT be sent through the tunnel identified in that TLV, unless U1 is
  carrying the Color Extended Community that is identified in U2's
  Color Sub-TLV.") doesn't seem to strictly apply.

Semantics and behavior need to be specified - not just the encodings, and that is all this draft currently has.

2) Sec 5.1 and Sec 5.2 refer to the format of the Encapsulation Sub-TLV and Protocol Sub-TLV coming from draft-ietf-idr-tunnel-encaps-06 - but that draft defines not merely the format, but allocates an IANA registry for additional sub-types that can appear and defines the format and contents of the sub-TLV based upon the tunnel type.  I'm nearly certain that you mean that these sub-tlvs use not merely the same format (does variable length fields based upon the allocated type cause issues for OSPF sub-TLV parsing???) but can contain any values and sub-TLVs defined in the relevant IANA registry. As it is written now, there is no reference to the registry or ability to easily support more tunnel types in the future.

3) It is unfortunate that Geneve, which is the agreed encapsulation for NVO3, is not included in the set of tunnels but VXLAN-GPE, which is not going to be a standard, is.
I know this is duplicating what is in draft-ietf-idr-tunnel-encaps-06 but it emphasizes the need to assume additional Tunnel Types and related Encapsulation Sub-TLVs will be defined.

4) Sec 4: Is there a reason to create a new IGP Tunnel Encapsulation Types registry instead of reusing BGP Tunnel Encapsulation Attribute Tunnel Types (https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types)?  The latter is FCFS and the proposed registry is Standards Action.  There are already differences and collisions between the two (i.e. value 15).
What would happen if an Encapsulation Sub-TLV needed to include a Tunnel Type? Which registry would it pull from? Would the value used depend on the protocol it was signaled in?

5) I-D.ietf-idr-tunnel-encaps has to be a normative reference.

6) Given that some of the references are to in progress documents for the tunnel types, is it expected that the values will correspond to future versions or are they nailed to this particular version or something else?


Nits:

a) Sec 1:"Partial deployment of IPv6 in IPv4 networks or IPv6 in IPv4
      networks as described in [RFC5565]"
s/IPv6 in IPv4/IPv4 in IPv6 for one of the two

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)? Why is this the
    proper type of RFC? Is this type of RFC indicated in the title page
    header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.

(2) The IESG approval announcement includes a Document Announcement
    Write-Up.  Please provide such a Document Announcement Write-Up.
    Recent examples can be found in the "Action" announcements for
    approved documents. The approval announcement contains the following
    sections:

Technical Summary:

      This document specifies extensions to OSPF Router Informational
      (RI) to advertise multiple node tunnel capabilities and associated
      tunnel parameters (e.g., endpoint). These tunnel capabilities can
      then be used to determine whether an OSPF router can act as the
      endpoint for a specific tunnel type (i.e., encapsulation).

Working Group Summary:

      There was concern that the document didn't satisfy a real
      requirement and was unnecessary. Much of the debate transpired
      in the IS-IS WG. Subsequently, consensus was reached on the
      attendant use cases. 

Document Quality:

      This document has been a WG document for more than 1 1/2 yeara
      and has been stable other than addressing minor comments.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alia Atlas is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by
    the Document Shepherd. If this version of the document is not ready
    for publication, please explain why the document is being forwarded
    to the IESG.

    The document shepherd has reviewed each revision of the document
    and followed the discussion on the OSPF mailing list.


(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

      No.

(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization? If so, describe the review
    that took place.

      No.

(6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or
    the IESG should be aware of? For example, perhaps he or she is
    uncomfortable with certain parts of the document, or has concerns
    whether there really is a need for it. In any event, if the WG has
    discussed those issues and has indicated that it still wishes to
    advance the document, detail those concerns here.

      None.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of BCP
    78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

      No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with it?

      There is consensus from the WG and others outside the WG that
      this document can progress. The corresponding document has been
      accepted in as a WG document in the IS-IS WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
    discontent?  If so, please summarise the areas of conflict in
    separate email messages to the Responsible Area Director. (It
    should be in a separate email because this questionnaire is
    publicly available.)

      No.

(11) Identify any ID nits the Document Shepherd has found in this
    document.  (See http://www.ietf.org/tools/idnits/ and the
    Internet-Drafts Checklist).  Boilerplate checks are not enough;
    this check needs to be thorough.

      Nits are all resolved.

(12) Describe how the document meets any required formal review
    criteria, such as the MIB Doctor, media type, and URI type reviews.

      Not applicable.

(13) Have all references within this document been identified as either
    normative or informative?

      Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state? If such
    normative references exist, what is the plan for their completion?
 
      No. Publication has been requested for the RFC 4970 BIS draft.

(15) Are there downward normative references references (see RFC 3967)?
    If so, list these downward references to support the Area Director
    in the Last Call procedure.

      No.

(16) Will publication of this document change the status of any existing
    RFCs?  Are those RFCs listed on the title page header, listed in
    the abstract, and discussed in the introduction? If the RFCs are
    not listed in the Abstract and Introduction, explain why, and point
    to the part of the document where the relationship of this document
    to the other RFCs is discussed. If this information is not in the
    document, explain why the WG considers it unnecessary.

      No.

(17) Describe the Document Shepherd's review of the IANA considerations
    section, especially with regard to its consistency with the body of
    the document.  Confirm that all protocol extensions that the
    document makes are associated with the appropriate reservations in
    IANA registries. Confirm that any referenced IANA registries have
    been clearly identified. Confirm that newly created IANA registries
    include a detailed specification of the initial contents for the
    registry, that allocations procedures for future registrations are
    defined, and a reasonable name for the new registry has been
    suggested (see RFC 5226).
 
      This document defines a new OSPF Router Information LSA
      TLV, Tunnel Capabilities TLV, to the OSPF Router Information (RI)
      TLVs Registry. Additionally, two new registeries are created, one
      for IGP tunnel encapsulation types and another for tunnel
      encapsulation attribute Sub-TLVs.

      The IANA actions are clear. However, the created registries should
      be verified for correctness.

(18) List any new IANA registries that require Expert Review for future
    allocations. Provide any public guidance that the IESG would find
    useful in selecting the IANA Experts for these new registries.

      Both the new registries require "Standards Action". Hence, they
      will be reviewed by current WG experts.

(19) Describe reviews and automated checks performed by the Document
    Shepherd to validate sections of the document written in a formal
    language, such as XML code, BNF rules, MIB definitions, etc.

      Not applicable.

Request for posting confirmation emailed to previous authors: Robert Raszuk , Xiaohu Xu , Bruno Decraene , Luay Jalil , Uma Chunduri , Luis Contreras , ospf-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Robert Raszuk , Xiaohu Xu , Bruno Decraene , Luay Jalil , Uma Chunduri , Luis Contreras , ospf-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Xiaohu Xu" , "Bruno Decraene" , "Luay Jalil" , "Uma Chunduri" , "Robert Raszuk" , ospf-chairs@ietf.org, "Luis Contreras"