The BGP Tunnel Encapsulation Attribute
draft-ietf-idr-tunnel-encaps-22
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2021-03-17
|
22 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2021-03-01
|
22 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2021-02-15
|
22 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2021-02-09
|
22 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2021-02-08
|
22 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2021-02-08
|
22 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-02-08
|
22 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-02-08
|
22 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2021-01-26
|
22 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2021-01-15
|
22 | (System) | RFC Editor state changed to EDIT |
2021-01-15
|
22 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2021-01-15
|
22 | (System) | Announcement was received by RFC Editor |
2021-01-15
|
22 | (System) | IANA Action state changed to In Progress |
2021-01-15
|
22 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2021-01-15
|
22 | Cindy Morgan | IESG has approved the document |
2021-01-15
|
22 | Cindy Morgan | Closed "Approve" ballot |
2021-01-15
|
22 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2021-01-15
|
22 | Alvaro Retana | Ballot approval text was generated |
2021-01-15
|
22 | Magnus Westerlund | [Ballot comment] This document fails massively the alone on an island test. No one can implement this without having the specification from an operator for … [Ballot comment] This document fails massively the alone on an island test. No one can implement this without having the specification from an operator for what they actually want to establish. This in its turn makes it impossible to answer if there are issues or not and additional configuration are needed for things like UDP zero-checksum, ECN, ICMP processing etc. All these nitty gritty details that can make a tunnel work good or not from an upper layer protocol perspective. |
2021-01-15
|
22 | Magnus Westerlund | [Ballot Position Update] Position for Magnus Westerlund has been changed to Abstain from Discuss |
2021-01-11
|
22 | Benjamin Kaduk | [Ballot comment] Thank you for the discussion and clarifications relating to my discuss point, as well as all the other updates to the document. |
2021-01-11
|
22 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2021-01-09
|
22 | Erik Kline | [Ballot comment] [ section 3.3.1 ] https://www.rfc-editor.org/rfc/rfc2474.html#section-3 says this about the term "DS field": Six bits of the DS field are used as a … [Ballot comment] [ section 3.3.1 ] https://www.rfc-editor.org/rfc/rfc2474.html#section-3 says this about the term "DS field": Six bits of the DS field are used as a codepoint (DSCP) to select the PHB a packet experiences at each node. A two-bit currently unused (CU) field is reserved and its definition and interpretation are outside the scope of this document. The value of the CU bits are ignored by differentiated services-compliant nodes when determining the per-hop behavior to apply to a received packet. The DS field structure is presented below: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | DSCP | CU | +---+---+---+---+---+---+---+---+ DSCP: differentiated services codepoint CU: currently unused So, if this section 3.3.1 one byte DS field is meant to be the same (i.e. includes the 2 CU bits that are now ECN bits), then I'm good with this. Thanks. |
2021-01-09
|
22 | Erik Kline | [Ballot Position Update] Position for Erik Kline has been changed to No Objection from Discuss |
2021-01-07
|
22 | John Scudder | New version available: draft-ietf-idr-tunnel-encaps-22.txt |
2021-01-07
|
22 | (System) | New version accepted (logged-in submitter: John Scudder) |
2021-01-07
|
22 | John Scudder | Uploaded new revision |
2021-01-07
|
21 | Roman Danyliw | [Ballot comment] Thank you to Scott Kelly for performing the SECDIR review. Thank you for addressing my DISCUSS and COMMENT feedback. |
2021-01-07
|
21 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss |
2021-01-07
|
21 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2021-01-07
|
21 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2021-01-07
|
21 | John Scudder | New version available: draft-ietf-idr-tunnel-encaps-21.txt |
2021-01-07
|
21 | (System) | New version approved |
2021-01-07
|
21 | (System) | Request for posting confirmation emailed to previous authors: Gunter Van de Velde , John Scudder , Keyur Patel , Srihari Sangli |
2021-01-07
|
21 | John Scudder | Uploaded new revision |
2020-12-09
|
20 | Bernie Volz | Assignment of request for Telechat review by INTDIR to David Lamparter was marked no-response |
2020-12-09
|
20 | Bernie Volz | Assignment of request for Telechat review by INTDIR to Basavaraj Patil was marked no-response |
2020-12-03
|
20 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2020-12-03
|
20 | Roman Danyliw | [Ballot discuss] Per the conversation on my original COMMENT (thanks for the quick response), https://mailarchive.ietf.org/arch/msg/idr/hV2t6-8mq2dOvmXO-PvLuiON5o4/, I'm escalating this item to a DISCUSS. Section 11 … [Ballot discuss] Per the conversation on my original COMMENT (thanks for the quick response), https://mailarchive.ietf.org/arch/msg/idr/hV2t6-8mq2dOvmXO-PvLuiON5o4/, I'm escalating this item to a DISCUSS. Section 11 However, it is intended that the Tunnel Encapsulation attribute be used only within a well-defined scope, e.g., within a set of Autonomous Systems that belong to a single administrative entity. As this applicability text should be read as a normative SHOULD, please provide a discussion on the risks of open Internet usage in the Security Considerations. |
2020-12-03
|
20 | Roman Danyliw | [Ballot comment] Thank you to Scott Kelly for performing the SECDIR review. ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it … [Ballot comment] Thank you to Scott Kelly for performing the SECDIR review. ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.”, this seems inconsistent with the meta-data header in the document (as RFC8365 isn’t obsoleted). ** (original COMMENT, see DISCUSS above) Section 11. Please use normative language on the applicability text restricting use to a single administrative domain. OLD However, it is intended that the Tunnel Encapsulation attribute be used only within a well-defined scope, e.g., within a set of Autonomous Systems that belong to a single administrative entity. NEW (or something like this) However, the Tunnel Encapsulation attribute MUST only be used within a well-defined scope such as a set of Autonomous Systems that belong to a single administrative entity. ** Section 12. Typo. s/tunnelling/tunneling/ ** Section 15. Clarifying text OLD "hijacking" of traffic (insertion of an undesired node in the path) NEW "hijacking" of traffic (insertion of an undesired node in the path allowing for inspection or modification of traffic, or avoidance of security controls) |
2020-12-03
|
20 | Roman Danyliw | [Ballot Position Update] Position for Roman Danyliw has been changed to Discuss from No Objection |
2020-12-03
|
20 | Benjamin Kaduk | [Ballot discuss] [Updated to remove the point about the "relationship between this document and RFC 8365"; no other changes] I support Erik's discuss. I … [Ballot discuss] [Updated to remove the point about the "relationship between this document and RFC 8365"; no other changes] I support Erik's discuss. I see that Roman has already suggested adding normative language regarding the limitation to a single administrative domain (in addition to the "MUST filter by default for EBGP sessions"), which I agree with. However, I think there is an additional consideration regarding the limitation of use to a single administrative domain, wherein the domain of use for the tunnel encapsulation attribute may diverge from the domain of use of segment routing, that seems to place this document in conflict with the requirements of RFC 8402. In particular, RFC 8402 says, for SR-MPLS and SRv6, that boundary routers "MUST filter any external traffic", and additionally for SRv6 that "explicit routing information MUST NOT be leaked through the boundaries of the administrered domain". In §3.7 of this document, though, we find that for the Prefix-SID sub-TLV, "the receiving BGP speaker need not even be in the same Segment Routing Domain as the tunnel's egress endpoint, and there is no implication that the prefix-SID for the advertised prefix is the same in the Segment Routing domains of the BGP speaker that originated the sub-TLV and the BGP speaker that received it", which seems to suggest violation of the RFC 8402 requirement. I think we need to have greater clarity on what relationship is actually intended between the SR domain and the tunnel encapsulation usage domain, and if they are to diverge, we need to both somehow rectify this behavior with RFC 8402 and to very clearly document how the 8402-mandated filtering at the SR domain boundary is supposed to happen when the boundary includes tunneled traffic. |
2020-12-03
|
20 | Benjamin Kaduk | Ballot discuss text updated for Benjamin Kaduk |
2020-12-03
|
20 | Magnus Westerlund | [Ballot discuss] So this is really to start a discussion of how the framework approach of this document may not be explicit enough on what … [Ballot discuss] So this is really to start a discussion of how the framework approach of this document may not be explicit enough on what combination is actually viable combination and have existing specification for how to deal with a number of behaviors for tunnels. So my view after having read this one is that the signalling is specified in a two tier fashion, with an outer encapsulation that can be IPvX, IPvX/UDP for example and then a tunnel protocol like GRE, VXLAN, L2TPv3. So I don't believe all combinations of outer encapsulation and tunnel protocol is actually defined. This document does not provide a table with the reference for where the actual data plan specification for combinations are provided. I think it would be good if there actually existed such a table/list. The next aspect of this discuss is the difficulty in determining if the provided sub-TLVs are sufficient. I will mention a number of potential ones that I wonder if they are necessary to configure these combinations. To build on Erik Kline's discuss. So are for all these combinations when IP is the outer encapsulation is the egress ECN behavior to correctly mark or drop inner payload well defined. If the egress is not guaranteed to do the correct, then I think a configuration option is required. When using UDP encapsulation combined with IPv6 there is the question if one can safely use zero-checksum. Per RFC 6935 and RFC 6936 some consideration is needed to determine if the inner payload is safe to combine with zero checksum. So this requires the combination of tunnel protocol and inner payload to determine this. So I think some of these tunnel protocols have text on this, but I don't know which combinations have this specified. And also here arise a question if some of these will also need a configuration option as there exist some inner payloads that could not be safe and thus a different tunnel with checksum enabled may be required. When using UDP encapsulation I am wondering over source port usage. To my knowledge some of these protocols like VXLAN do defines that source ports are picked randomly to ensure header hashing will provide different values for different inner flows. So is there a need in any of this cases to identify a single source port? So I at least are unable to determine if this specification are containing all necessary attributes when it doesn't have identification of what combinations it expect to work, and what behavior on the above aspects is just working. So lets start discussing what needs to be addressed here if any. |
2020-12-03
|
20 | Magnus Westerlund | [Ballot Position Update] New position, Discuss, has been recorded for Magnus Westerlund |
2020-12-02
|
20 | Murray Kucherawy | [Ballot comment] Throughout the document it seemed like a lot of care had been taken in the appropriate use of SHOULDs and MUSTs. Nice work. … [Ballot comment] Throughout the document it seemed like a lot of care had been taken in the appropriate use of SHOULDs and MUSTs. Nice work. In addition to Barry's comments about the IANA Considerations section, please state in Section 14.1 which registry/registries are to be updated. |
2020-12-02
|
20 | Murray Kucherawy | [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy |
2020-12-02
|
20 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2020-12-02
|
20 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2020-12-01
|
20 | Barry Leiba | [Ballot comment] For the new registries defined in Sections 14.6 through 14.9, it would help both IANA and the reader if the definition specified the … [Ballot comment] For the new registries defined in Sections 14.6 through 14.9, it would help both IANA and the reader if the definition specified the range of values: for the bit fields, how many bits are available? For the numeric field in 14.8, what’s the valid numeric range? |
2020-12-01
|
20 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2020-12-01
|
20 | Martin Duke | [Ballot comment] I support Erik's DISCUSS. Thank you for Section 1.3; it was extremely helpful to understand what this spec is trying to accomplish. In … [Ballot comment] I support Erik's DISCUSS. Thank you for Section 1.3; it was extremely helpful to understand what this spec is trying to accomplish. In Sec 3.1 it says there MUST be exactly one Tunnel Egress Endpoint sub-TLV but describes an error if there are zero sub-TLVs. In Sec 13 this is correctly specified as anything other than 1 sub-TLV. Please update 3.1 to match. |
2020-12-01
|
20 | Martin Duke | [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke |
2020-12-01
|
20 | Benjamin Kaduk | [Ballot discuss] I support Erik's discuss. I see that Roman has already suggested adding normative language regarding the limitation to a single administrative domain (in … [Ballot discuss] I support Erik's discuss. I see that Roman has already suggested adding normative language regarding the limitation to a single administrative domain (in addition to the "MUST filter by default for EBGP sessions"), which I agree with. However, I think there is an additional consideration regarding the limitation of use to a single administrative domain, wherein the domain of use for the tunnel encapsulation attribute may diverge from the domain of use of segment routing, that seems to place this document in conflict with the requirements of RFC 8402. In particular, RFC 8402 says, for SR-MPLS and SRv6, that boundary routers "MUST filter any external traffic", and additionally for SRv6 that "explicit routing information MUST NOT be leaked through the boundaries of the administrered domain". In §3.7 of this document, though, we find that for the Prefix-SID sub-TLV, "the receiving BGP speaker need not even be in the same Segment Routing Domain as the tunnel's egress endpoint, and there is no implication that the prefix-SID for the advertised prefix is the same in the Segment Routing domains of the BGP speaker that originated the sub-TLV and the BGP speaker that received it", which seems to suggest violation of the RFC 8402 requirement. I think we need to have greater clarity on what relationship is actually intended between the SR domain and the tunnel encapsulation usage domain, and if they are to diverge, we need to both somehow rectify this behavior with RFC 8402 and to very clearly document how the 8402-mandated filtering at the SR domain boundary is supposed to happen when the boundary includes tunneled traffic. I also would like to ensure that we have had adequate discussion of the relationship between this document and RFC 8365. The IESG has received comments recently (in the context of a different document) that it is irresponsible to effectively obsolete or deprecate existing work without identifying or explicitly updating such work, and without indicating whose responsibility it is to find discrepancies. That seems like it might apply to what's currently in Appendix A, which on first reading suggests "there might be a problem here, but we aren't saying exactly what or how to fix it, or even who is going to do that work". |
2020-12-01
|
20 | Benjamin Kaduk | [Ballot comment] It's good to see that the shepherd writeup got updated as things changed; thank you for keeping it up to date! [I initially … [Ballot comment] It's good to see that the shepherd writeup got updated as things changed; thank you for keeping it up to date! [I initially wrote some inline comments about handling internal inconsistencies within a given tunnel specification as malformed and ignoring the tunnel entirely vs specifying a precedence order (the latter being what this document does). I removed them, because this seems to be a generic topic where security types tend to fail-closed and routing types tend to aim to provide some kind of service when possible, and I don't have anything new to add to the discussion for these particular cases.] I didn't see a response to the secdir review; it would be good to get a response to that, in particular to hear what amount of consideration has been given to what new ways this provides to attack BGP. Abstract of certain other SAFIs. This document adds support for additional Tunnel Types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for The shepherd writeup suggests that the "remote tunnel endpoint" terminology was switched to be "tunnel egress endpoint"; was this spot missed? Section 1.4 o Defining a new "Tunnel Egress Endpoint sub-TLV" (Section 3.1) that can be included in any of the TLVs contained in the Tunnel Encapsulation attribute. This sub-TLV can be used to specify the remote endpoint address of a particular tunnel. ["remote endpoint" again] Section 3.1 I agree with Martin V that there must be a story about this Reserved field and why it's only SHOULD send as zero. I don't know whether this information needs to end up in the RFC but I think we should talk about why it is this way. In particular, the current requirements suggest that it could be (mis?)used as an additional data channel by collaborating implementations (that ignore the "MUST be disregarded"), without actually writing up a specification for those semantics. If the Address Family subfield has any value other than IPv4 or IPv6, the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" (see We probably need to repeat the carve-out for the value 0 here, as well. (I dithered about remarking about the earlier "assumes that the Address Family is either IPv4 or IPv6" since the "one special case" is a few paragraphs later.) o It can be determined that the IP address in the sub-TLV's address subfield does not belong to the Autonomous System (AS) that originated the route that contains the attribute. Section 3.1.1 describes an optional procedure to make this determination. This check seems highly important for the security of the system and should get called out in the security considerations. Section 3.1.1 sub-TLV is considered not to be valid. In some cases a network operator who controls a set of Autonomous Systems might wish to allow a Tunnel Egress Endpoint to reside in an AS other than Route_AS; configuration MAY allow for such a case, in which case the check becomes, if Egress_AS is not within the configured set of permitted AS numbers, then the Tunnel Egress Endpoint sub-TLV is considered to be "malformed". (nit?) maybe "the configured set of permitted AS numbers that contains Route_AS"? The current wording implies that there can only be one such configured set and that it is used regardless of Route_AS, which does not seem right... Section 3.2 This section defines Encapsulation sub-TLVs for the following tunnel types: VXLAN ([RFC7348]), NVGRE ([RFC7637]), MPLS-in-GRE ([RFC4023]), L2TPv3 ([RFC3931]), and GRE ([RFC2784]). Thanks for putting the links all in one place, here. I, at least, would have benefited from also putting the links/references in the corresponding sections, but that is probably just a matter of style. Section 3.2.1 R: The remaining bits in the 8-bit flags field are reserved for further use. They MUST always be set to 0 by the originator of the sub-TLV. Intermediate routers MUST propagate them without modification. Any receiving routers MUST ignore these bits upon a receipt of the sub-TLV. nit: spurious "a" in "upon a receipt" (and diffing this section against §3.2.2 it seems that maybe the "of the sub-TLV" is also superfluous?). o If the V bit is not set, and the BGP UPDATE message has AFI/SAFI other than Ethernet VPNs (EVPN) then the VXLAN tunnel cannot be used. If this is intended to refer to SAFI 70 (from RFC 7432), I note that the IANA entry is named "BGP EVPNs". [I also don't understand why it's okay for EVPN to not have a VN-ID when using the VXLAN tunnel, but assume that's just my ignorance.] Section 3.2.2 Reserved (two fields): MUST be set to zero on transmission and disregarded on receipt. (nit) I only see one field marked "Reserved" (this format is the same layout as for VXLAN). o The values of the V, M, and R bits are NOT copied into the flags field of the NVGRE header. The flags field of the VXLAN header is set as per [RFC7637]. (nit) stray "VXLAN"? Section 3.2.5 While it is not really necessary to have both the GRE and MPLS-in-GRE tunnel types, both are included for reasons of backwards compatibility. It might be nice to have a few more words about which one is the "backward compatible" option and what it's compatible with. Section 3.3 If an outer Encapsulation sub-TLV occurs in a TLV for a Tunnel Type that does not use the corresponding outer encapsulation, the sub-TLV MUST be treated as if it were an unknown type of sub-TLV. nit: this is the only instance of "unknown" in the document; using "unrecognized" seems to be the common case (and makes it easier to find Section 13). Section 3.3.1 I think we may need to discuss the semantics of the DS field here -- as I understand it, the attribute advertised in this TLV is the DSCP value that the BGP speaker would like to receive in traffic destined to the tunnel egress endpoint (which may be a different node than the BGP speaker itself, but is expected to be under the control of the same administrative entity). Additionally, the interpretation of DSCP values is subject to local interpretation on a given network. Since the tunnel encapsulation attribute is transitive, it will be propagated potentially across multiple BGP hops and multiple ASes, so that the tunnel ingress endpoint is not necessarily adjacent to the tunnel egress endpoint. Although we do say that we expect the tunnel encapsulation information to only be propagated within an administrative boundary, there is no guarantee that the administrative boundary in question uses a unified DSCP handling procedure throughout it. As such, it may be possible to end up in a regime where the requested DSCP codepoint has a different, and potentially hazardous, interpretation, at the ingress of the tunnel. So, it seems that we need to say something about either local policy for DSCP value filtering, or only using this value when "directly" connected to the egress AS, or similar; we do have something like this already for the TC portion of the MPLS label stack entries. Section 3.5 labeled address family, then the sub-TLV MUST be disregarded. If the sub-TLV is contained in a TLV whose Tunnel Type does not have a virtual network identifier in its encapsulation header, the sub-TLV MUST be disregarded. In those cases where the sub-TLV is ignored, it SHOULD NOT be stripped from the TLV before the route is propagated. Why only SHOULD NOT here? I thought we hat MUST-level requirements to preserve things unchaged in similar situations. Section 4.1 In the remainder of this specification, when a route is referred to as containing a Tunnel Encapsulation attribute with a TLV identifying a particular Tunnel Type, it implicitly includes the case where the route contains a Tunnel Encapsulation Extended Community identifying that Tunnel Type. I searched the entire document for the string "identifying" and did not find any instances where a route was referred to as containing a Tunenl Encapsulation attribute with a TLV identifying a particular tunnel type. Perhaps I should be looking for the "attribute" keyword, but there are over 200 instances of that string; could you confirm whether this implicit inclusion is actually used anywhere (and if so, give an example of such usage)? Section 6 [RFC5512] specifies the use of the Tunnel Encapsulation attribute in BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. That document restricts the use of this attribute to UPDATE messages of those SAFIs. This document removes that restriction. I believe another reviewer commented on the ambiguity of "that", which I first thought referred to "this" vs "that"; I now see that there is additional ambituity as to whether it is the SAFI restriction or the UPDATE message restriction that is lifted, and suggest clarification of that as well. Once it is determined to send a packet through the tunnel specified in a particular Tunnel TLV of a particular Tunnel Encapsulation attribute, then the tunnel's egress endpoint address is the IP address contained in the sub-TLV. If the Tunnel TLV contains a nit: I think we have to say "Tunnel Egress Endpoint sub-TLV"; the use of the definite article is not justified by the preceding context. Section 8 However, suppose that one of the TLVs in U2's Tunnel Encapsulation attribute contains the Color Sub-TLV. In that case, packet P MUST NOT be sent through the tunnel contained in that TLV, unless U1 is carrying the Color Extended Community that is identified in U2's Color Sub-TLV. We should probably reword this in light of Section 13's discussion that a given Tunnel TLV can have more than one Color sub-TLV present. Section 9.2 Three of the tunnel types that can be specified in a Tunnel Encapsulation TLV have virtual network identifier fields in their encapsulation headers. In the VXLAN encapsulation, this field is called the VNI (Virtual Network Identifier) field; in the NVGRE encapsulation, this field is called the VSID (Virtual Subnet Identifier) field. We start off by saying "three" types but list only two. What's the third type? Section 9.2.2.2 If the TLV identifying the tunnel does not contain an Encapsulation sub-TLV whose V bit is set, the virtual network identifier field of the encapsulation header is set as follows: This perhaps sets us up for a nasty surprise in light of the error-handling behavior in §13, where we are supposed to disregard the second and subsequent instances of the Encapsulation sub-TLV. This language is not particularly clear about whether it applies to only the first sub-TLV or all instances. o If the TLV does not contain an Embedded Label Handling sub-TLV, or if it contains an Embedded Label Handling sub-TLV whose value is 2, the embedded label is copied into the lower 3 octets of the virtual network identifier field of the encapsulation header. nit: I think "lower" is unneeded, since all the VNI fields are exactly 3 octets now. Section 10 Note that if the Tunnel Encapsulation attribute is attached to a VPN- IP route [RFC4364], and if Inter-AS "option b" (see section 10 of [RFC4364]) is being used, and if the Tunnel Egress Endpoint sub-TLV contains an IP address that is not in same AS as the router receiving the route, it is very likely that the embedded label has been changed. [...] I'm not sure that I'm understanding this scenario properly. The label has been "changed" with respect to what baseline? I'm also not sure why the tunnel egress endpoint would need to be in the same AS as the router receiving (vs originating) the route. Other documents may define other ways to signal tunnel information in BGP. For example, [RFC6514] defines the "P-Multicast Service Interface Tunnel" (PMSI Tunnel) attribute. In this specification, we do not consider the effects of advertising the Tunnel Encapsulation Attribute in conjunction with other forms of signaling tunnels. Any document specifying such joint use should provide details as to how interactions should be handled. It seems like we should perhaps go a step further and explicitly recommend not advertising such combinations in the absence of a specification for their combined use? Otherwise implementations will have to come up with their own interpretations, which could easily be uninteroperable. Section 13 The following sub-TLVs defined in this document MUST NOT occur more than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed below), Encapsulation, DS, UDP Destination Port, Embedded Label Handling, MPLS Label Stack, Prefix-SID. [...] Ah, thanks for listing these out. I had been wondering about this situation earlier in the doc, and it would have helped if the "not more than once" limitation was mentioned at each sub-TLV's definition (even if the actual error handling stays here). Section 14.3 Why do we only move "BGP Tunnel Encapsulation Attribute Sub-TLVs" (but not "BGP Tunnel Encapsulation Attribute Tunnel Types") to the new "BGP Tunnel Encapsulation Parameters" grouping? Section 14.9 It might be useful to indicate in the registry metadata how many flags are available (and, I suppose, in which order the bits are numbered). Section 15 We briefly discuss in the main body text the possibility that a tunnel will direct encapsulated traffic with (e.g) MPLS labels to a node that will misinterpret those labels; it might be worth reiterating the risk of such misinterpretation in the security considerations as well (or just referencing the previous discussion as security-relevant). I guess there's also a theoretical possibility that the flexibility in tunnel specification (including the type of expected content) could facilitate cross-protocol attacks, where the attacker causes the sender and recipient of encapsulated traffic to think that they should interpret the records in question as different protocols. But this seems so remote, and unlikely to succeed given different protocols' message structure, that it is probably not worth mentioning. Section 18.2 If we're using RFC 5462 as a reference for a field in an MPLS label, that seems to make it normative. We seem to depend on procedures from RFC 6811 in a few places, which also seems to make it normative. |
2020-12-01
|
20 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2020-11-30
|
20 | Erik Kline | [Ballot discuss] [ section 3.3.1 ] * The text about "[a]ny one-octet value can be transported" leaves me wondering about how values that result … [Ballot discuss] [ section 3.3.1 ] * The text about "[a]ny one-octet value can be transported" leaves me wondering about how values that result in ECN bits being set should be treated. I think there needs to be some recognition here that the DSCP part of the octet is only 6 bits (2474 section 3), and that bits 6 & 7 "MUST/SHOULD be zero on transmission and MUST/SHOULD be ignored by the recipient". Another way to ask the question here is: if ECN is not to be specified as part of this octet (and IMHO it should not be), which ranges of 6 bit values are permitted: [0..63], with the understanding this will be shifted before setting the octet, or [0,4,8,12,...,252]? Given the text "It specifies the setting of the one-octet...", I think it implies the latter, but some clarification would, I think, be helpful. |
2020-11-30
|
20 | Erik Kline | [Ballot comment] [[ questions ]] [ section 3.1 ] * The prohibition against use of Forwardable=false egress IPs I think means that IPv4 and … [Ballot comment] [[ questions ]] [ section 3.1 ] * The prohibition against use of Forwardable=false egress IPs I think means that IPv4 and IPv6 link-local addresses cannot be used. It seems somewhat unusual, but not completely outside the realm of reasonable, to have a situation where two on-link routers could be configured by their respective administrators to use some encapsulation for forwarded packets without having to resort to global unicast addresses. Are we sure this (odd) use case should be prohibited? The final paragraph of this section seems to cover the use of non-reachable addresses just fine. Obviously link-local IPs would need to be exempt from section 3.1.1 AS-owned address validation. [ section 3.3+ ] * Do any implementations wish to set IPv6 flow labels? [ section 6 ] * Might MTU overhead a consideration in tunnel selection? I.e., given more than one tunnel option might an implementation choose based on minimizing total overhead? |
2020-11-30
|
20 | Erik Kline | [Ballot Position Update] New position, Discuss, has been recorded for Erik Kline |
2020-11-30
|
20 | Warren Kumari | [Ballot comment] Thanks to Jouni for the Opsdir review, and authors for addressing them (https://mailarchive.ietf.org/arch/msg/idr/MkQPOktdsUZAkxgv9iqtJgdG4HE) |
2020-11-30
|
20 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2020-11-30
|
20 | Roman Danyliw | [Ballot comment] Thank you to Scott Kelly for performing the SECDIR review. ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it … [Ballot comment] Thank you to Scott Kelly for performing the SECDIR review. ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.”, this seems inconsistent with the meta-data header in the document (as RFC8365 isn’t obsoleted). ** Section 11. Please use normative language on the applicability text restricting use to a single administrative domain. OLD However, it is intended that the Tunnel Encapsulation attribute be used only within a well-defined scope, e.g., within a set of Autonomous Systems that belong to a single administrative entity. NEW (or something like this) However, the Tunnel Encapsulation attribute MUST only be used within a well-defined scope such as a set of Autonomous Systems that belong to a single administrative entity. ** Section 12. Typo. s/tunnelling/tunneling/ ** Section 15. Clarifying text OLD "hijacking" of traffic (insertion of an undesired node in the path) NEW "hijacking" of traffic (insertion of an undesired node in the path allowing for inspection or modification of traffic, or avoidance of security controls) |
2020-11-30
|
20 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2020-11-30
|
20 | Roman Danyliw | [Ballot comment] Thank you to Scott Kelly for performing the SECDIR review. ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it … [Ballot comment] Thank you to Scott Kelly for performing the SECDIR review. ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.”, this seems inconsistent with the meta-data header in the document (as RFC8365 isn’t obsoleted). ** Section 11. Please use normative language on the applicability text restricting use to a single administrative domain. OLD However, it is intended that the Tunnel Encapsulation attribute be used only within a well-defined scope, e.g., within a set of Autonomous Systems that belong to a single administrative entity. NEW (or something like this) However, the Tunnel Encapsulation attribute MUST only be used within a well-defined scope such as a set of Autonomous Systems that belong to a single administrative entity. ** Section 12. Typo. s/tunnelling/tunneling/ ** Section 14.2. Per “Specifically, the following code points should be marked as deprecated”, how does one mark code points as deprecated in the “BGP Tunnel Encapsulation Attribute Tunnel Types” registry (https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types). I don’t see such a column, or is the intend simply to update the Reference column to this document? ** Section 15. Clarifying text OLD "hijacking" of traffic (insertion of an undesired node in the path) NEW "hijacking" of traffic (insertion of an undesired node in the path allowing for inspection or modification of traffic, or avoidance of security controls) |
2020-11-30
|
20 | Roman Danyliw | Ballot comment text updated for Roman Danyliw |
2020-11-30
|
20 | Roman Danyliw | [Ballot comment] ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.”, this seems inconsistent with the meta-data header … [Ballot comment] ** Section 1.5. Per “Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.”, this seems inconsistent with the meta-data header in the document (as RFC8365 isn’t obsoleted). ** Section 11. Please use normative language on the applicability text restricting use to a single administrative domain. OLD However, it is intended that the Tunnel Encapsulation attribute be used only within a well-defined scope, e.g., within a set of Autonomous Systems that belong to a single administrative entity. NEW (or something like this) However, the Tunnel Encapsulation attribute MUST only be used within a well-defined scope such as a set of Autonomous Systems that belong to a single administrative entity. ** Section 12. Typo. s/tunnelling/tunneling/ ** Section 14.2. Per “Specifically, the following code points should be marked as deprecated”, how does one mark code points as deprecated in the “BGP Tunnel Encapsulation Attribute Tunnel Types” registry (https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types). I don’t see such a column, or is the intend simply to update the Reference column to this document? ** Section 15. Clarifying text OLD "hijacking" of traffic (insertion of an undesired node in the path) NEW "hijacking" of traffic (insertion of an undesired node in the path allowing for inspection or modification of traffic, or avoidance of security controls) |
2020-11-30
|
20 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2020-11-30
|
20 | Robert Wilton | [Ballot comment] Hi, Thanks for this document. I have no significant comments. Like Martin, I'm also somewhat confused by this text "Because RFC 8365 depends … [Ballot comment] Hi, Thanks for this document. I have no significant comments. Like Martin, I'm also somewhat confused by this text "Because RFC 8365 depends on RFC 5640, it is similarly obsoleted.", since it appears that RFC 8365 isn't really being formally obsoleted. From a manageability perspective, are there any addition data nodes required to the BGP YANG data model, or augmentations to that model? If so, are these being taken care of in another draft or subsumed into existing YANG modelling work? Regards, Rob |
2020-11-30
|
20 | Robert Wilton | [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton |
2020-11-30
|
20 | Éric Vyncke | [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points, and one generic nit. I hope that … [Ballot comment] Thank you for the work put into this document. Please find below some non-blocking COMMENT points, and one generic nit. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- A very generic comment about the abstract that is mainly about RFC 5512. I find it a little surprising as it describes the protocol that this document obsoletes... I would have preferred an abstract describing what this document does w/o citing RFC 5512 (except of course at the end of the abstract). -- Section 1.4 -- It is a little unclear what "these deficiencies" are ? Perhaps add a reference to previous section 1.2 ? -- Section 3 -- Would it be easier for the reader to either have a summary table of all sub-TLV types or repeat the type code in all sub-section headings? -- Section 3.2.1 and 3.2.2 -- While the assumption of a 48-bit MAC address is correct in 2020 (barring FireWire, IEEE 802.5.14), it also limits the usability of this document to a set of data-link layers. Should the length of the "Reserved" field be specified ? -- Section 3.3 -- Should the value of IPv6 Flow Label or any IPv6 extension header (e.g., hop by hop or destination headers) be specified ? -- Section 3.6 -- If not mistaken, RFC 8669 is only about SR-MPLS. So, I wonder whether the authors also think to add a similar feature for SRv6 ? -- Sections 5 & 12 -- Unsure whether this paragraph is really useful, isn't it implicit ? (I am of course fine in either case) == NITS == I find the choice of "encapsulation sub-TLV" a poor choice as it can easily be confused with "encapsulation TLV" (section 2) but I guess the train has left the station ;-) |
2020-11-30
|
20 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2020-11-29
|
20 | Martin Vigoureux | [Ballot comment] Hi thank you for the work you put in this document. I only have minor comments/questions (though a couple of ones might be … [Ballot comment] Hi thank you for the work you put in this document. I only have minor comments/questions (though a couple of ones might be a bit more important than the rest). Because RFC 8365 depends on RFC 5640, it is similarly obsoleted. This is further discussed in Appendix A. But neither the abstract nor the metadata mention this, and in fact Appendix A is not clear about whether RFC 8365 is effectively obsoleted. Not critical but IANA registration of the Tunnel Encapsulation Attribute is with a upper-case 'A', while through out the document lower-case 'a' is used. A Tunnel Encapsulation TLV, also known as Tunnel TLV but in the document you most often omit using Tunnel, thus reducing it to TLV. The Reserved subfield SHOULD be originated as zero. It MUST be disregarded on receipt, and it MUST be propagated unchanged. In the rest of the document, for unused bits or reserved fields you require MUST be zero. Any reason for different levels of requirements? The Address Family subfield contains a value from IANA's "Address Family Numbers" registry. This document assumes that the Address Family is either IPv4 or IPv6; use of other address families is outside the scope of this document. If the Address Family subfield has any value other than IPv4 or IPv6, the Tunnel Egress Endpoint sub-TLV is considered "unrecognized" Not critical but I have the impression that these two paragraphs slightly contradict each other. First one allows for other AFIs to be used in the future in the Address Family subfield, while the second kind of rules that out. Maybe simply add at the beginning of the second paragraph: "In the context of this specification,". Note that in order to send an IP packet or an MPLS packet through a VXLAN tunnel, the packet must first be encapsulated in an Ethernet header, which becomes the "inner Ethernet header" described in [RFC7348]. The VXLAN Encapsulation sub-TLV may contain information (e.g.,the MAC address) that is used to form this Ethernet header. This seems redundant with the last paragraph of the second bullet above (in the document) sub-TLVs must be used MUST? 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | 0 or 1 | +-+-+-+-+-+-+-+-+ Should the values be 1 or 2 instead? At least the text says the only two allowed values are 1 and 2. If a Label-Index is present in the Prefix-SID sub-TLV, then when a packet is sent through the tunnel identified by the TLV, if that tunnel is from a labeled address family do you mean from "a BGP UPDATE of a labeled address family" ? document specifying such joint use should provide details SHOULD? +--------------+--------------------------------+-----------------+ | 0 | V (Virtual Network Identifier) | (this document) | +--------------+-----------------+-----------------+ | 0 | V (VN-ID) | (this document) | Purely cosmetic, but may be choose VN-ID or Virtual Network Identifier as the same name for the two allocations. Nits "Value Field" in the Fig1 and Fig2 legends seems superfluous. s/In this case, the length field/In this case, the Length field/ s/address subfield/Address subfield/ (6 occurrences) s/depicted in the Address Field/depicted in the Address subfield/ (3 occurrences, including Section 3.1.1 title) s/Tunnel Type itself/tunnel type itself/? s/value field/Value field/ (17 occurrences + 6 occurrences with line break between the two words) s/Reserved (two fields)/Reserved (two octets)/ (twice) s/The flags field of the VXLAN header/The flags field of the NVGRE header/ (in the NVGRE section) s/Inner Destination MAC address/Inner Destination MAC Address/ s/of the cookie/of the Cookie/ s/procedures of Section 9/procedures of Section 9)/ s/VNI (Virtual Network Identifier)/VNI (VXLAN Network Identifier)/ |
2020-11-29
|
20 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2020-11-24
|
20 | Bernie Volz | Request for Telechat review by INTDIR is assigned to David Lamparter |
2020-11-24
|
20 | Bernie Volz | Request for Telechat review by INTDIR is assigned to David Lamparter |
2020-11-24
|
20 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Basavaraj Patil |
2020-11-24
|
20 | Bernie Volz | Request for Telechat review by INTDIR is assigned to Basavaraj Patil |
2020-11-24
|
20 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-11-20
|
20 | Éric Vyncke | Requested Telechat review by INTDIR |
2020-11-19
|
20 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2020-11-19
|
20 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Scott Kelly. Submission of review completed at an earlier date. |
2020-11-15
|
20 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Scott Kelly. |
2020-11-13
|
20 | Amy Vezza | Placed on agenda for telechat - 2020-12-03 |
2020-11-13
|
20 | Alvaro Retana | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::External Party |
2020-11-13
|
20 | Alvaro Retana | Ballot has been issued |
2020-11-13
|
20 | Alvaro Retana | [Ballot Position Update] New position, Yes, has been recorded for Alvaro Retana |
2020-11-13
|
20 | Alvaro Retana | Created "Approve" ballot |
2020-11-13
|
20 | Alvaro Retana | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? Proposed Standard. The document defines procedures and operation for BGP. Further, it makes requests to IANA and obsoletes a PS RFC. The header indicates Standards Track. (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 RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document went through two full WGLCs. The first one, for draft -04, generated a substantial amount of discussion. It concluded on June 9, 2017 without consensus to proceed, but did result in extensive review and discussion, with all points that were raised either being reflected in the later versions of the draft, or otherwise resolved. The chairs' summary of the WGLC is at https://www.ietf.org/mail-archive/web/idr/current/msg18246.html The second one, for draft -07 (with cc OSPF and BESS since they both normatively reference the draft) concluded October 20, 2017 with some support and no dissent. Given the extensive review and discussion as part of the first WGLC, the chairs were satisified with this outcome. Subsequent to the second WGLC, further issues were reported by implementors (this is why IDR has an implementation requirement!). Some issues also were found by the document shepherd in the course of preparing this report. The related updates brought the draft version up to -12. We had an "additional comment period" to allow the WG to raise any concerns related to the changes, the thread can be found at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=3_Fmk0Ble3VaAaDzAqt7heOpfc4 Finally, an editorial issue was surfaced in the course of a WG discussion about a number of different SD-WAN related proposals. A number of readers considered the use of the term "remote tunnel endpoint" confusing since it wasn't clear from what point of view the tunnel was considered "remote". That discussion can be found, in part, at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=vPmpkz7tPWfo0laWHRtLayMF5ZA Although it sprawled across a few threads, this is the one that concludes them. The authors eventually decided to revise their terminology to change "remote tunnel endpoint" to "tunnel egress endpoint" in -13; this settled the issue. John Scudder, the initial WG shepherd, added so much in the editorial process that the co-authors felt John should be a co-author. Due to this the Shepherd was changed to Susan Hares with version 19 (-19.txt). Susan Hares did a fresh analysis of the internet draft. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The IDR implementation report page is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The initial document shepherd was John Scudder The current document shepherd is Susan Hares. The responsible AD is Alvaro Retana. (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 read the draft in detail several times during the course of its development, and worked with the authors to address comments. This includes a review of the current version. The document shepherd took a fresh review of the document. This review took the followinng steps: 1) Examination of the technology within its use cases, the RFC deprecated (RFC 5512, RFC5566, RFC5640), any RFC related to this work (RFC7510) or with an alternate tunnel approach with BGP support (PMSI, RFC8365). The list of drafts related to PMSI approach included many of the MVPN and EVPn work done by L3VPN, L2VPN or BESS (RFC7432, RFC8277, RFC6514, RFC7153, RFC7432, RFC 7524, RFC7716,. RFC7988), and the EVPN BESS drafts approved for publication draft-ietf-bess-evpn-prefix-advertisement). 2) Exmination of the use of tunnels for NSH control plane for SFC . BESS has approved drafts-ietf-bess-nsh-bgp-control-plane-18 for publication. 3) Examination of IDR Drafts approved for publication for BGP-LS/Segment Routing and flow specification (draft-ietf-bgp-ls-sgement-routing-ext-16.txt draft-ietf-bgpls-segment-routing-epe-19.txt, draft-ietf-idr-rfc5575bis.txt). 4) The shepherd also examined all drafts adopted by BESS and IDR for interactions with the tunnel-encapsulation specification. 5) The shepherd also reviewd the -19.txt version for textual consistency. The shepherd wrote up the results in a 16 page write-up that was sent to Alvaro, John Scudder and the author group. A majority of the write-up was a report on the RFC and drafts in BESS and IDR described above. The report indicated 6 technical points plus editorial points. -20.txt addressed technical and editorial points in the write-up. The tunnel-encapsulation work and related work in VPNs, (IP-VPNs, EVPNs, M-VPNs, etc) stands on the shoulders of work in IDR, L3VPN, L2VPN BESS. The authors have carefully inserted the GP tunnel-encapsulation attribute into this complex set of VPN technology. This draft provides a careful insertion with notes on what RFCs are obsoleted. The shpeherd notes that other VPN drafts (EVPN, VPN for SFC, NVO3 VPN, M-VPN, SR VPNs) that rely on tunnels need to be as careful in their examination of the existing technology. As a WG chair of IDR, this shepherd will pass along the insights learned to IDR and BESS chairs. The second shepherd has worked with 3 proposals for replacement of the secure IP-VPN tunnel type using the tunnel-encapsulation for 3 years. These implementations have three different types of application (within an AS or AS-Confederation, SDWAN, and Secure E-VPN. The proposed implementations were vetted by the security experts at an open meeting at IETF 104. This work in secure IP-VPN is moving slower than the general tunnel-encapsulation. Since IDR requires 2 implementations to forward drafts to the IESG, the IP-in IP tunnel with IPSec transport and the MPLS-in-IP tunnel with IPsec Transport were deprecated. It is expected that the replacement for these deprecated functions will eventually mature to the point of having 2 interoperable implementations (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. IETF LC reviews were request for Internet Directorate (tunnel MTUs), Op/NM directorate, Security Directorate and Transport Directorate. All directorate reviews received have been addressed by -20.txt. The security directorate reviewed has not completed the review as of 11/6/2020. (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. Authors have so confirmed. (see discussion -04.txt) Keyur Patel: https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/ Gunter Van de Velde https://mailarchive.ietf.org/arch/msg/idr/HVP3wzhaIA8PkIrS4Pem9Gb6qAE/ Srihari R. Sangli https://mailarchive.ietf.org/arch/msg/idr/xjaGqKL4VTpvTApXOs0wwo_ag1E/ John Scudder: https://mailarchive.ietf.org/arch/msg/idr/A5m3eu6-5VPHUbmWk_TxgYeBJyg/ Eric Rosen (RFC 5512 author) https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. no IPR disclosure. (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? Considering the amount of conversation on the mailing list and at the in-person meetings, discussed above under "working group summary", I'd say it has broad consensus. The draft has implementations in cisco (partial), FRR (Free Range Routing, partail), and JunOS (full). In addition, these implementations have increased functionality since initial IETF LC. https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations (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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Bogus comment on RFC5566 and RFC5640 since text states: "Since RFCs 5566 and 5640 rely on RFC 5512, they are likewise obsoleted." I will suggest to authors in the next revision to place "RFC5566 and RFC5640" to make Id nits stop complaining Idnits complains about downrefs. See answer to (15). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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. (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. Note: during IETF LC o RFC 7348 ("Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks") o RFC 7637 ("NVGRE: Network Virtualization Using Generic Routing Encapsulation") These two are Informational, ISE stream documents. The relevant case in RFC 3967 is: o A standards document may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs. These downrefs are needed. (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. Yes, RFC 5512, RFC5566, and RFC5640 are obsoleted and the reasons adequately discussed. [RFC8365] references RFC 5512 for its definition of the BGP Encapsulation Extended Community. The impact of deprecating RFC5512 is discussed in Appendix A. A RFC8365bis is recommended. (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). Confirmed. (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. N/A (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. N/A |
2020-11-12
|
20 | Susan Hares | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? Proposed Standard. The document defines procedures and operation for BGP. Further, it makes requests to IANA and obsoletes a PS RFC. The header indicates Standards Track. (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 RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document went through two full WGLCs. The first one, for draft -04, generated a substantial amount of discussion. It concluded on June 9, 2017 without consensus to proceed, but did result in extensive review and discussion, with all points that were raised either being reflected in the later versions of the draft, or otherwise resolved. The chairs' summary of the WGLC is at https://www.ietf.org/mail-archive/web/idr/current/msg18246.html The second one, for draft -07 (with cc OSPF and BESS since they both normatively reference the draft) concluded October 20, 2017 with some support and no dissent. Given the extensive review and discussion as part of the first WGLC, the chairs were satisified with this outcome. Subsequent to the second WGLC, further issues were reported by implementors (this is why IDR has an implementation requirement!). Some issues also were found by the document shepherd in the course of preparing this report. The related updates brought the draft version up to -12. We had an "additional comment period" to allow the WG to raise any concerns related to the changes, the thread can be found at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=3_Fmk0Ble3VaAaDzAqt7heOpfc4 Finally, an editorial issue was surfaced in the course of a WG discussion about a number of different SD-WAN related proposals. A number of readers considered the use of the term "remote tunnel endpoint" confusing since it wasn't clear from what point of view the tunnel was considered "remote". That discussion can be found, in part, at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=vPmpkz7tPWfo0laWHRtLayMF5ZA Although it sprawled across a few threads, this is the one that concludes them. The authors eventually decided to revise their terminology to change "remote tunnel endpoint" to "tunnel egress endpoint" in -13; this settled the issue. John Scudder, the initial WG shepherd, added so much in the editorial process that the co-authors felt John should be a co-author. Due to this the Shepherd was changed to Susan Hares with version 19 (-19.txt). Susan Hares did a fresh analysis of the internet draft. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The IDR implementation report page is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The initial document shepherd was John Scudder The current document shepherd is Susan Hares. The responsible AD is Alvaro Retana. (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 read the draft in detail several times during the course of its development, and worked with the authors to address comments. This includes a review of the current version. The document shepherd took a fresh review of the document. This review took the followinng steps: 1) Examination of the technology within its use cases, the RFC deprecated (RFC 5512, RFC5566, RFC5640), any RFC related to this work (RFC7510) or with an alternate tunnel approach with BGP support (PMSI, RFC8365). The list of drafts related to PMSI approach included many of the MVPN and EVPn work done by L3VPN, L2VPN or BESS (RFC7432, RFC8277, RFC6514, RFC7153, RFC7432, RFC 7524, RFC7716,. RFC7988), and the EVPN BESS drafts approved for publication draft-ietf-bess-evpn-prefix-advertisement). 2) Exmination of the use of tunnels for NSH control plane for SFC . BESS has approved drafts-ietf-bess-nsh-bgp-control-plane-18 for publication. 3) Examination of IDR Drafts approved for publication for BGP-LS/Segment Routing and flow specification (draft-ietf-bgp-ls-sgement-routing-ext-16.txt draft-ietf-bgpls-segment-routing-epe-19.txt, draft-ietf-idr-rfc5575bis.txt). 4) The shepherd also examined all drafts adopted by BESS and IDR for interactions with the tunnel-encapsulation specification. 5) The shepherd also reviewd the -19.txt version for textual consistency. The shepherd wrote up the results in a 16 page write-up that was sent to Alvaro, John Scudder and the author group. A majority of the write-up was a report on the RFC and drafts in BESS and IDR described above. The report indicated 6 technical points plus editorial points. -20.txt addressed technical and editorial points in the write-up. The tunnel-encapsulation work and related work in VPNs, (IP-VPNs, EVPNs, M-VPNs, etc) stands on the shoulders of work in IDR, L3VPN, L2VPN BESS. The authors have carefully inserted the GP tunnel-encapsulation attribute into this complex set of VPN technology. This draft provides a careful insertion with notes on what RFCs are obsoleted. The shpeherd notes that other VPN drafts (EVPN, VPN for SFC, NVO3 VPN, M-VPN, SR VPNs) that rely on tunnels need to be as careful in their examination of the existing technology. As a WG chair of IDR, this shepherd will pass along the insights learned to IDR and BESS chairs. The second shepherd has worked with 3 proposals for replacement of the secure IP-VPN tunnel type using the tunnel-encapsulation for 3 years. These implementations have three different types of application (within an AS or AS-Confederation, SDWAN, and Secure E-VPN. The proposed implementations were vetted by the security experts at an open meeting at IETF 104. This work in secure IP-VPN is moving slower than the general tunnel-encapsulation. Since IDR requires 2 implementations to forward drafts to the IESG, the IP-in IP tunnel with IPSec transport and the MPLS-in-IP tunnel with IPsec Transport were deprecated. It is expected that the replacement for these deprecated functions will eventually mature to the point of having 2 interoperable implementations (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. IETF LC reviews were request for Internet Directorate (tunnel MTUs), Op/NM directorate, Security Directorate and Transport Directorate. All directorate reviews received have been addressed by -20.txt. The security directorate reviewed has not completed the review as of 11/6/2020. (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. Authors have so confirmed. (see discussion -04.txt) Keyur Patel: https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/ Gunter Van de Velde https://mailarchive.ietf.org/arch/msg/idr/HVP3wzhaIA8PkIrS4Pem9Gb6qAE/ Srihari R. Sangli https://mailarchive.ietf.org/arch/msg/idr/xjaGqKL4VTpvTApXOs0wwo_ag1E/ John Scudder: https://mailarchive.ietf.org/arch/msg/idr/A5m3eu6-5VPHUbmWk_TxgYeBJyg/ Eric Rosen (RFC 5512 author) https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. no IPR disclosure. (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? Considering the amount of conversation on the mailing list and at the in-person meetings, discussed above under "working group summary", I'd say it has broad consensus. The draft has implementations in cisco (partial), FRR (Free Range Routing, partail), and JunOS (full). In addition, these implementations have increased functionality since initial IETF LC. https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations (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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Bogus comment on RFC5566 and RFC5640 since text states: "Since RFCs 5566 and 5640 rely on RFC 5512, they are likewise obsoleted." I will suggest to authors in the next revision to place "RFC5566 and RFC5640" to make Id nits stop complaining Idnits complains about downrefs. See answer to (15). See resolution in (15). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? Original shephred (John Scudder): Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe. The NVO3 chairs state that their WG plans to advance this draft following advancement of Geneve, and that Geneve has been sent to the IESG for advancement. So, it appears GPE will be ready for advancement soon. Sue: Advancement is slow so John Scudder and Author team will move draft--ietf-nv03-vxlan-gpe out of document in next revision. (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. (See two note sections denoted as Note 1 and Note 2) Note 1: during IETF LC o RFC 7348 ("Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks") o RFC 7637 ("NVGRE: Network Virtualization Using Generic Routing Encapsulation") o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN") The first two are Informational, ISE stream documents. The relevant case in RFC 3967 is: o A standards document may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs. draft-ietf-nvo3-vxlan-gpe which currently lists its intended status as "informational"; the authors and NVO3 chairs confirm this is correct. It's my opinion that this downref is ok in the spirit of the above, even though the draft is an IETF product. Given that the tunnel-encaps specification is extensible, it seems overly restrictive to prevent it from being extended to signal a particular encapsulation just because that encapsulation is specified in an informational document. Importantly, the "informational" references, while normative in the sense that the specification can't be fully understood without understanding the references as well, are NOT required for the core elements of the specification. It would be possible to produce an implementation of the specification that complies and interoperates but doesn't support any of the encapsulations in the downref specs. (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. Yes, RFC 5512, RFC5566, and RFC5640 are obsoleted and the reasons adequately discussed. [RFC8365] references RFC 5512 for its definition of the BGP Encapsulation Extended Community. The impact of deprecating RFC5512 is discussed in Appendix A. A RFC8365bis is recommended. (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). Confirmed. (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. N/A (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. N/A |
2020-11-10
|
20 | Susan Hares | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? Proposed Standard. The document defines procedures and operation for BGP. Further, it makes requests to IANA and obsoletes a PS RFC. The header indicates Standards Track. (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 RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document went through two full WGLCs. The first one, for draft -04, generated a substantial amount of discussion. It concluded on June 9, 2017 without consensus to proceed, but did result in extensive review and discussion, with all points that were raised either being reflected in the later versions of the draft, or otherwise resolved. The chairs' summary of the WGLC is at https://www.ietf.org/mail-archive/web/idr/current/msg18246.html The second one, for draft -07 (with cc OSPF and BESS since they both normatively reference the draft) concluded October 20, 2017 with some support and no dissent. Given the extensive review and discussion as part of the first WGLC, the chairs were satisified with this outcome. Subsequent to the second WGLC, further issues were reported by implementors (this is why IDR has an implementation requirement!). Some issues also were found by the document shepherd in the course of preparing this report. The related updates brought the draft version up to -12. We had an "additional comment period" to allow the WG to raise any concerns related to the changes, the thread can be found at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=3_Fmk0Ble3VaAaDzAqt7heOpfc4 Finally, an editorial issue was surfaced in the course of a WG discussion about a number of different SD-WAN related proposals. A number of readers considered the use of the term "remote tunnel endpoint" confusing since it wasn't clear from what point of view the tunnel was considered "remote". That discussion can be found, in part, at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=vPmpkz7tPWfo0laWHRtLayMF5ZA Although it sprawled across a few threads, this is the one that concludes them. The authors eventually decided to revise their terminology to change "remote tunnel endpoint" to "tunnel egress endpoint" in -13; this settled the issue. John Scudder, the initial WG shepherd, added so much in the editorial process that the co-authors felt John should be a co-author. Due to this the Shepherd was changed to Susan Hares with version 19 (-19.txt). Susan Hares did a fresh analysis of the internet draft. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The IDR implementation report page is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The initial document shepherd was John Scudder The current document shepherd is Susan Hares. The responsible AD is Alvaro Retana. (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 read the draft in detail several times during the course of its development, and worked with the authors to address comments. This includes a review of the current version. The document shepherd took a fresh review of the document. This review took the followinng steps: 1) Examination of the technology within its use cases, the RFC deprecated (RFC 5512, RFC5566, RFC5640), any RFC related to this work (RFC7510) or with an alternate tunnel approach with BGP support (PMSI, RFC8365). The list of drafts related to PMSI approach included many of the MVPN and EVPn work done by L3VPN, L2VPN or BESS (RFC7432, RFC8277, RFC6514, RFC7153, RFC7432, RFC 7524, RFC7716,. RFC7988), and the EVPN BESS drafts approved for publication draft-ietf-bess-evpn-prefix-advertisement). 2) Exmination of the use of tunnels for NSH control plane for SFC . BESS has approved drafts-ietf-bess-nsh-bgp-control-plane-18 for publication. 3) Examination of IDR Drafts approved for publication for BGP-LS/Segment Routing and flow specification (draft-ietf-bgp-ls-sgement-routing-ext-16.txt draft-ietf-bgpls-segment-routing-epe-19.txt, draft-ietf-idr-rfc5575bis.txt). 4) The shepherd also examined all drafts adopted by BESS and IDR for interactions with the tunnel-encapsulation specification. 5) The shepherd also reviewd the -19.txt version for textual consistency. The shepherd wrote up the results in a 16 page write-up that was sent to Alvaro, John Scudder and the author group. A majority of the write-up was a report on the RFC and drafts in BESS and IDR described above. The report indicated 6 technical points plus editorial points. -20.txt addressed technical and editorial points in the write-up. The tunnel-encapsulation work and related work in VPNs, (IP-VPNs, EVPNs, M-VPNs, etc) stands on the shoulders of work in IDR, L3VPN, L2VPN BESS. The authors have carefully inserted the GP tunnel-encapsulation attribute into this complex set of VPN technology. This draft provides a careful insertion with notes on what RFCs are obsoleted. The shpeherd notes that other VPN drafts (EVPN, VPN for SFC, NVO3 VPN, M-VPN, SR VPNs) that rely on tunnels need to be as careful in their examination of the existing technology. As a WG chair of IDR, this shepherd will pass along the insights learned to IDR and BESS chairs. The second shepherd has worked with 3 proposals for replacement of the secure IP-VPN tunnel type using the tunnel-encapsulation for 3 years. These implementations have three different types of application (within an AS or AS-Confederation, SDWAN, and Secure E-VPN. The proposed implementations were vetted by the security experts at an open meeting at IETF 104. This work in secure IP-VPN is moving slower than the general tunnel-encapsulation. Since IDR requires 2 implementations to forward drafts to the IESG, the IP-in IP tunnel with IPSec transport and the MPLS-in-IP tunnel with IPsec Transport were deprecated. It is expected that the replacement for these deprecated functions will eventually mature to the point of having 2 interoperable implementations (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. IETF LC reviews were request for Internet Directorate (tunnel MTUs), Op/NM directorate, Security Directorate and Transport Directorate. All directorate reviews received have been addressed by -20.txt. The security directorate reviewed has not completed the review as of 11/6/2020. (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. Authors have so confirmed. (see discussion -04.txt) Keyur Patel: https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/ Gunter Van de Velde https://mailarchive.ietf.org/arch/msg/idr/HVP3wzhaIA8PkIrS4Pem9Gb6qAE/ Srihari R. Sangli https://mailarchive.ietf.org/arch/msg/idr/xjaGqKL4VTpvTApXOs0wwo_ag1E/ John Scudder: https://mailarchive.ietf.org/arch/msg/idr/A5m3eu6-5VPHUbmWk_TxgYeBJyg/ Eric Rosen (RFC 5512 author) https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. no IPR disclosure. (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? Considering the amount of conversation on the mailing list and at the in-person meetings, discussed above under "working group summary", I'd say it has broad consensus. The draft has implementations in cisco (partial), FRR (Free Range Routing, partail), and JunOS (full). In addition, these implementations have increased functionality since initial IETF LC. https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations (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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Bogus comment on RFC5566 and RFC5640 since text states: "Since RFCs 5566 and 5640 rely on RFC 5512, they are likewise obsoleted." I will suggest to authors in the next revision to place "RFC5566 and RFC5640" to make Id nits stop complaining Idnits complains about downrefs. See answer to (15). See resolution in (15). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? Original shephred (John Scudder): Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe. The NVO3 chairs state that their WG plans to advance this draft following advancement of Geneve, and that Geneve has been sent to the IESG for advancement. So, it appears GPE will be ready for advancement soon. Sue: Advancement is slow so John Scudder and Author team will move draft--ietf-nv03-vxlan-gpe out of document in next revision. (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. (See two note sections denoted as Note 1 and Note 2) Note 1: during IETF LC o RFC 7348 ("Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks") o RFC 7637 ("NVGRE: Network Virtualization Using Generic Routing Encapsulation") o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN") The first two are Informational, ISE stream documents. The relevant case in RFC 3967 is: o A standards document may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs. draft-ietf-nvo3-vxlan-gpe which currently lists its intended status as "informational"; the authors and NVO3 chairs confirm this is correct. It's my opinion that this downref is ok in the spirit of the above, even though the draft is an IETF product. Given that the tunnel-encaps specification is extensible, it seems overly restrictive to prevent it from being extended to signal a particular encapsulation just because that encapsulation is specified in an informational document. Importantly, the "informational" references, while normative in the sense that the specification can't be fully understood without understanding the references as well, are NOT required for the core elements of the specification. It would be possible to produce an implementation of the specification that complies and interoperates but doesn't support any of the encapsulations in the downref specs. Note 2: Post IETF L process: After IETF LC, the authors have agreed to move out this these two references into another document. (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. Yes, RFC 5512, RFC5566, and RFC5640 are obsoleted and the reasons adequately discussed. [RFC8365] references RFC 5512 for its definition of the BGP Encapsulation Extended Community. The impact of deprecating RFC5512 is discussed in Appendix A. A RFC8365bis is recommended. (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). Confirmed. (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. N/A (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. N/A |
2020-11-10
|
20 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2020-11-10
|
20 | John Scudder | New version available: draft-ietf-idr-tunnel-encaps-20.txt |
2020-11-10
|
20 | (System) | Forced post of submission |
2020-11-10
|
20 | (System) | Request for posting confirmation emailed to previous authors: John Scudder , Gunter Van de Velde , Keyur Patel , Srihari Sangli |
2020-11-10
|
20 | John Scudder | Uploaded new revision |
2020-11-07
|
19 | Susan Hares | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? Proposed Standard. The document defines procedures and operation for BGP. Further, it makes requests to IANA and obsoletes a PS RFC. The header indicates Standards Track. (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 RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document went through two full WGLCs. The first one, for draft -04, generated a substantial amount of discussion. It concluded on June 9, 2017 without consensus to proceed, but did result in extensive review and discussion, with all points that were raised either being reflected in the later versions of the draft, or otherwise resolved. The chairs' summary of the WGLC is at https://www.ietf.org/mail-archive/web/idr/current/msg18246.html The second one, for draft -07 (with cc OSPF and BESS since they both normatively reference the draft) concluded October 20, 2017 with some support and no dissent. Given the extensive review and discussion as part of the first WGLC, the chairs were satisified with this outcome. Subsequent to the second WGLC, further issues were reported by implementors (this is why IDR has an implementation requirement!). Some issues also were found by the document shepherd in the course of preparing this report. The related updates brought the draft version up to -12. We had an "additional comment period" to allow the WG to raise any concerns related to the changes, the thread can be found at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=3_Fmk0Ble3VaAaDzAqt7heOpfc4 Finally, an editorial issue was surfaced in the course of a WG discussion about a number of different SD-WAN related proposals. A number of readers considered the use of the term "remote tunnel endpoint" confusing since it wasn't clear from what point of view the tunnel was considered "remote". That discussion can be found, in part, at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=vPmpkz7tPWfo0laWHRtLayMF5ZA Although it sprawled across a few threads, this is the one that concludes them. The authors eventually decided to revise their terminology to change "remote tunnel endpoint" to "tunnel egress endpoint" in -13; this settled the issue. John Scudder, the initial WG shepherd, added so much in the editorial process that the co-authors felt John should be a co-author. Due to this the Shepherd was changed to Susan Hares with version 19 (-19.txt). Susan Hares did a fresh analysis of the internet draft. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The IDR implementation report page is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The initial document shepherd was John Scudder The current document shepherd is Susan Hares. The responsible AD is Alvaro Retana. (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 read the draft in detail several times during the course of its development, and worked with the authors to address comments. This includes a review of the current version. The document shepherd took a fresh review of the document. This review took the followinng steps: 1) Examination of the technology within its use cases, the RFC deprecated (RFC 5512, RFC5566, RFC5640), any RFC related to this work (RFC7510) or with an alternate tunnel approach with BGP support (PMSI, RFC8365). The list of drafts related to PMSI approach included many of the MVPN and EVPn work done by L3VPN, L2VPN or BESS (RFC7432, RFC8277, RFC6514, RFC7153, RFC7432, RFC 7524, RFC7716,. RFC7988), and the EVPN BESS drafts approved for publication draft-ietf-bess-evpn-prefix-advertisement). 2) Exmination of the use of tunnels for NSH control plane for SFC . BESS has approved drafts-ietf-bess-nsh-bgp-control-plane-18 for publication. 3) Examination of IDR Drafts approved for publication for BGP-LS/Segment Routing and flow specification (draft-ietf-bgp-ls-sgement-routing-ext-16.txt draft-ietf-bgpls-segment-routing-epe-19.txt, draft-ietf-idr-rfc5575bis.txt). 4) The shepherd also examined all drafts adopted by BESS and IDR for interactions with the tunnel-encapsulation specification. 5) The shepherd also reviewd the -19.txt version for textual consistency. The shepherd wrote up the results in a 16 page write-up that was sent to Alvaro, John Scudder and the author group. A majority of the write-up was a report on the RFC and drafts in BESS and IDR described above. The report indicated 6 technical points plus editorial points. -20.txt addressed technical and editorial points in the write-up. The tunnel-encapsulation work and related work in VPNs, (IP-VPNs, EVPNs, M-VPNs, etc) stands on the shoulders of work in IDR, L3VPN, L2VPN BESS. The authors have carefully inserted the GP tunnel-encapsulation attribute into this complex set of VPN technology. This draft provides a careful insertion with notes on what RFCs are obsoleted. The shpeherd notes that other VPN drafts (EVPN, VPN for SFC, NVO3 VPN, M-VPN, SR VPNs) that rely on tunnels need to be as careful in their examination of the existing technology. As a WG chair of IDR, this shepherd will pass along the insights learned to IDR and BESS chairs. The second shepherd has worked with 3 proposals for replacement of the secure IP-VPN tunnel type using the tunnel-encapsulation for 3 years. These implementations have three different types of application (within an AS or AS-Confederation, SDWAN, and Secure E-VPN. The proposed implementations were vetted by the security experts at an open meeting at IETF 104. This work in secure IP-VPN is moving slower than the general tunnel-encapsulation. Since IDR requires 2 implementations to forward drafts to the IESG, the IP-in IP tunnel with IPSec transport and the MPLS-in-IP tunnel with IPsec Transport were deprecated. It is expected that the replacement for these deprecated functions will eventually mature to the point of having 2 interoperable implementations (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. IETF LC reviews were request for Internet Directorate (tunnel MTUs), Op/NM directorate, Security Directorate and Transport Directorate. All directorate reviews received have been addressed by -20.txt. The security directorate reviewed has not completed the review as of 11/6/2020. (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. Authors have so confirmed. (see discussion -04.txt) Keyur Patel: https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/ Gunter Van de Velde https://mailarchive.ietf.org/arch/msg/idr/HVP3wzhaIA8PkIrS4Pem9Gb6qAE/ Srihari R. Sangli [missing] John Scudder: [missing] Eric Rosen (RFC 5512 author) https://mailarchive.ietf.org/arch/msg/idr/uv9syrZ24jlArwSpIapNoRy_NME/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. N/A (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? Considering the amount of conversation on the mailing list and at the in-person meetings, discussed above under "working group summary", I'd say it has broad consensus. The draft also has (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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Note that the idnits error about an IPv4 address is bogus, idnits is confusing a section reference (9.1.2.1) for an IP address, possibly because of where the line break is? Idnits complains about downrefs. See answer to (15). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe. The NVO3 chairs state that their WG plans to advance this draft following advancement of Geneve, and that Geneve has been sent to the IESG for advancement. So, it appears GPE will be ready for advancement soon. (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. o RFC 7348 ("Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks") o RFC 7637 ("NVGRE: Network Virtualization Using Generic Routing Encapsulation") o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN") The first two are Informational, ISE stream documents. The relevant case in RFC 3967 is: o A standards document may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs. draft-ietf-nvo3-vxlan-gpe which currently lists its intended status as "informational"; the authors and NVO3 chairs confirm this is correct. It's my opinion that this downref is ok in the spirit of the above, even though the draft is an IETF product. Given that the tunnel-encaps specification is extensible, it seems overly restrictive to prevent it from being extended to signal a particular encapsulation just because that encapsulation is specified in an informational document. Importantly, the "informational" references, while normative in the sense that the specification can't be fully understood without understanding the references as well, are NOT required for the core elements of the specification. It would be possible to produce an implementation of the specification that complies and interoperates but doesn't support any of the encapsulations in the downref specs. (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. Yes, RFC 5512 is obsoleted and the reasons adequately discussed. (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). Confirmed. (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. N/A (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. N/A |
2020-10-07
|
19 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Harish Sitaraman. Submission of review completed at an earlier date. |
2020-10-05
|
19 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Harish Sitaraman. |
2020-10-04
|
19 | Jouni Korhonen | Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Jouni Korhonen. Sent review to list. |
2020-10-02
|
19 | Gyan Mishra | Request for Last Call review by GENART Completed: Ready. Reviewer: Gyan Mishra. Sent review to list. |
2020-10-02
|
19 | Gyan Mishra | Request for Last Call review by GENART Completed: Ready. Reviewer: Gyan Mishra. Sent review to list. |
2020-10-01
|
19 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2020-10-01
|
19 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-idr-tunnel-encaps-18. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-idr-tunnel-encaps-18. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are eleven actions which we must complete. First, on the IANA Matrix at: https://www.iana.org/protocols all references to RFC5512 will be changed to [ RFC-to-be ]. Second, in the BGP Tunnel Encapsulation Attribute Tunnel Types registry on the Border Gateway Protocol (BGP) Parameters registry page located at: https://www.iana.org/assignments/bgp-parameters/ the following tunnel types are to be marked as obsolete with [ RFC-to-be ] as the reference: 3: Transmit tunnel endpoint 4: IPsec in Tunnel-mode 5: IP in IP tunnel with IPsec Transport Mode 6: MPLS-in-IP tunnel with IPsec Transport Mode Third, in the BGP Tunnel Encapsulation Attribute Sub-TLVs registry also on the Border Gateway Protocol (BGP) Parameters registry page located at: https://www.iana.org/assignments/bgp-parameters/ the following TLVs are to be marked as obsolete with [ RFC-to-be ] as the reference: 3: IPsec Tunnel Authenticator 5: Load-Balancing Block Fourth, a new registry page will be created on the IANA Matrix called the "BGP Tunnel Encapsulation Parameters" registry page. Fifth, in the SAFI Values registry on the Subsequent Address Family Identifiers (SAFI) Parameters registry page located at: https://www.iana.org/assignments/safi-namespace/ the following value are to be marked as obsolete with [ RFC-to-be ] as the reference: 7: Encapsulation SAFI Sixth, the the BGP Tunnel Encapsulation Attribute Sub-TLVs registry also on the Border Gateway Protocol (BGP) Parameters registry page which is currently located at: https://www.iana.org/assignments/bgp-parameters/ is to be moved under into the new registry page created in step four of these IANA actions. A new note will be added to the registry as follows: "If the Sub-TLV Type is in the range from 0 to 127 inclusive, the Sub-TLV Length field contains one octet. If the Sub-TLV Type is in the range from 128-255 inclusive, the Sub-TLV Length field contains two octets." The registration policy for the newly moved registry is to be as follows: +----------+-------------------------+ | Value(s) | Registration Procedure | +----------+-------------------------+ | 0 | Reserved | | 1-63 | Standards Action | | 64-125 | First Come First Served | | 126-127 | Experimental Use | | 128-191 | Standards Action | | 192-252 | First Come First Served | | 253-254 | Experimental Use | | 255 | Reserved | +----------+-------------------------+ In the newly moved registry, the following entries are to be renamed: Value 6 (old name: Remote Endpoint) new name: Tunnel Egress Endpoint Value 7 (old name: IPv4 DS Field) new name: DS Field Seventh, a new registry is to be created called the Flags Field of VXLAN Encapsulation sub-TLV registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows: +--------------+--------------------------------+-----------------+ | Bit Position | Description | Reference | +--------------+--------------------------------+-----------------+ | 0 | V (Virtual Network Identifier) | [ RFC-to-be ] | | 1 | M (MAC Address) | [ RFC-to-be ] | +--------------+--------------------------------+-----------------+ Eighth, a new registry is to be created called the Flags Field of VXLAN GPE Encapsulation sub-TLV registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows: +--------------+-------------+-----------------+ | Bit Position | Description | Reference | +--------------+-------------+-----------------+ | 0 | V (VN-ID) | [ RFC-to-be ] | +--------------+-------------+-----------------+ Ninth, a new registry is to be created called the Flags Field of NVGRE Encapsulation sub-TLV registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows: +--------------+-----------------+-----------------+ | Bit Position | Description | Reference | +--------------+-----------------+-----------------+ | 0 | V (VN-ID) | [ RFC-to-be ] | | 1 | M (MAC Address) | [ RFC-to-be ] | +--------------+-----------------+-----------------+ Tenth, a new registry is to be created called the Embedded Label Handling sub-TLV registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are initial registrations in the new registry as follows: +-------+-------------------------------------+-----------------+ | Value | Description | Reference | +-------+-------------------------------------+-----------------+ | 1 | Payload of MPLS with embedded label | [ RFC-to-be ] | | 2 | no embedded label in payload | [ RFC-to-be ] | +-------+-------------------------------------+-----------------+ Eleventh, a new registry is to be created called the Color Extended Community Flags registry. The new registry is to be created on the registry page created in step four of these IANA actions. The registration policy for the new registry is Standards Action as defined in RFC 8126. There are no initial registrations in this new registry. The format of the new registry has fields for Bit Position, Description and Reference. The IANA Functions Operator understands that these are the only actions 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 meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2020-10-01
|
19 | Alvaro Retana | The IETF LC has concluded. The Document Shepherd changed late in the process; I'm holding this document pending the new shepherd's review. |
2020-10-01
|
19 | Alvaro Retana | IESG state changed to Schaad Expires April 21, 2017 [Page … IESG state changed to Schaad Expires April 21, 2017 [Page 19] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 o If multiple items are included, an order for the items needs to be defined. Using options from CoAP as an example, an application could state that the fields are to be ordered by the option number. o Applications need to ensure that the byte stream is going to be the same on both sides. Using options from CoAP might give a problem if the same relative numbering is kept. An intermediate node could insert or remove an option, changing how the relative number is done. An application would need to specify that the relative number must be re-encoded to be relative only to the options that are in the external data. 4.4. Signing and Verification Process In order to create a signature, a well-defined byte stream is needed. The Sig_struture is used to create the canonical form. This signing and verification process takes in the body information (COSE_Sign or COSE_Sign1), the signer information (COSE_Signature), and the application data (external source). A Sig_structure is a CBOR array. The fields of the Sig_struture in order are: 1. A text string identifying the context of the signature. The context string is: "Signature" for signatures using the COSE_Signature structure. "Signature1" for signatures using the COSE_Sign1 structure. "CounterSignature" for signatures used as counter signature attributes. 2. The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used. 3. The protected attributes from the signer structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used. This field is omitted for the COSE_Sign1 signature structure. 4. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero length binary string. (See Section 4.3 for application guidance on constructing this field.) 5. The payload to be signed encoded in a bstr type. The payload is placed here independent of how it is transported. Schaad Expires April 21, 2017 [Page 20] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 The CDDL fragment that describes the above text is. Sig_structure = [ context : "Signature" / "Signature1" / "CounterSignature", body_protected : empty_or_serialized_map, ? sign_protected : empty_or_serialized_map, external_aad : bstr, payload : bstr ] How to compute a signature: 1. Create a Sig_structure and populate it with the appropriate fields. 2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 14. 3. Call the signature creation algorithm passing in K (the key to sign with), alg (the algorithm to sign with), and ToBeSigned (the value to sign). 4. Place the resulting signature value in the 'signature' field of the array. The steps for verifying a signature are: 1. Create a Sig_structure object and populate it with the appropriate fields. 2. Create the value ToBeSigned by encoding the Sig_structure to a byte string, using the encoding described in Section 14. 3. Call the signature verification algorithm passing in K (the key to verify with), alg (the algorithm used sign with), ToBeSigned (the value to sign), and sig (the signature to be verified). In addition to performing the signature verification, the application may also perform the appropriate checks to ensure that the key is correctly paired with the signing identity and that the signing identity is authorized before performing actions. 4.5. Computing Counter Signatures Counter signatures provide a method of associating different signature generated by different signers with some piece of content. This is normally used to provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a Schaad Expires April 21, 2017 [Page 21] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 Timestamp). In this document, we allow for counter signatures to exist in a greater number of environments. As an example, it is possible to place a counter signature in the unprotected attributes of a COSE_Encrypt object. This would allow for an intermediary to either verify that the encrypted byte stream has not been modified, without being able to decrypt it, or for the intermediary to assert that an encrypted byte stream either existed at a given time or passed through it in terms of routing (i.e., a proxy signature). An example of a counter signature on a signature can be found in Appendix C.1.3. An example of a counter signature in an encryption object can be found in Appendix C.3.3. The creation and validation of counter signatures over the different items relies on the fact that the structure of the objects have the same structure. The elements are a set of protected attributes, a set of unprotected attributes, and a body, in that order. This means that the Sig_structure can be used in a uniform manner to get the byte stream for processing a signature. If the counter signature is going to be computed over a COSE_Encrypt structure, the body_protected and payload items can be mapped into the Sig_structure in the same manner as from the COSE_Sign structure. It should be noted that only a signature algorithm with appendix (see Section 8) can be used for counter signatures. This is because the body should be able to be processed without having to evaluate the counter signature, and this is not possible for signature schemes with message recovery. 5. Encryption Objects COSE supports two different encryption structures. COSE_Encrypt0 is used when a recipient structure is not needed because the key to be used is known implicitly. COSE_Encrypt is used the rest of the time. This includes cases where there are multiple recipients or a recipient algorithm other than direct is used. 5.1. Enveloped COSE Structure The enveloped structure allows for one or more recipients of a message. There are provisions for parameters about the content and parameters about the recipient information to be carried in the message. The protected parameters associated with the content are authenticated by the content encryption algorithm. The protected parameters associated with the recipient are authenticated by the recipient algorithm (when the algorithm supports it). Examples of parameters about the content are the type of the content and the content encryption algorithm. Examples of parameters about the Schaad Expires April 21, 2017 [Page 22] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 recipient are the recipient's key identifier and the recipient's encryption algorithm. The same techniques and structures are used for encrypting both the plain text and the keys. This is different from the approach used by both CMS [RFC5652] and JSON Web Encryption (JWE) [RFC7516] where different structures are used for the content layer and for the recipient layer. Two structures are defined: COSE_Encrypt to hold the encrypted content and COSE_recipient to hold the encrypted keys for recipients. Examples of encrypted messages can be found in Appendix C.3. The COSE_Encrypt structure can be encoded either tagged or untagged depending on the context it will be used in. A tagged COSE_Encrypt structure is identified by the CBOR tag TBD2. The CDDL fragment that represents this is: COSE_Encrypt_Tagged = #6.992(COSE_Encrypt) ; Replace 992 with TBD2 The COSE_Encrypt structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. ' ciphertext contains the cipher text encoded as a bstr. If the cipher text is to be transported independently of the control information about the encryption process (i.e., detached content) then the field is encoded as a nil value. recipients contains an array of recipient information structures. The type for the recipient information structure is a COSE_recipient. The CDDL fragment that corresponds to the above text is: COSE_Encrypt = [ Headers, ciphertext : bstr / nil, recipients : [+COSE_recipient] ] The COSE_recipient structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. Schaad Expires April 21, 2017 [Page 23] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 unprotected as described in Section 3. ciphertext contains the encrypted key encoded as a bstr. All encoded keys are symetric keys, the binary value of the key is the content. If there is not an encrypted key, then this field is encoded as a nil value. recipients contains an array of recipient information structures. The type for the recipient information structure is a COSE_recipient. (An example of this can be found in Appendix B.) If there are no recipient information structures, this element is absent. The CDDL fragment that corresponds to the above text for COSE_recipient is: COSE_recipient = [ Headers, ciphertext : bstr / nil, ? recipients : [+COSE_recipient] ] 5.1.1. Content Key Distribution Methods An encrypted message consists of an encrypted content and an encrypted CEK for one or more recipients. The CEK is encrypted for each recipient, using a key specific to that recipient. The details of this encryption depend on which class the recipient algorithm falls into. Specific details on each of the classes can be found in Section 12. A short summary of the five content key distribution methods is: direct: The CEK is the same as the identified previously distributed symmetric key or derived from a previously distributed secret. No CEK is transported in the message. symmetric key-encryption keys: The CEK is encrypted using a previously distributed symmetric KEK. key agreement: The recipient's public key and a sender's private key are used to generate a pairwise secret, a KDF is applied to derive a key, and then the CEK is either the derived key or encrypted by the derived key. key transport: The CEK is encrypted with the recipient's public key. No key transport algorithms are defined in this document. Schaad Expires April 21, 2017 [Page 24] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 passwords: The CEK is encrypted in a KEK that is derived from a password. No password algorithms are defined in this document. 5.2. Single Recipient Encrypted The COSE_Encrypt0 encrypted structure does not have the ability to specify recipients of the message. The structure assumes that the recipient of the object will already know the identity of the key to be used in order to decrypt the message. If a key needs to be identified to the recipient, the enveloped structure ought to be used. Examples of encrypted messages can be found in Appendix C.3. The COSE_Encrypt0 structure can be encoded either tagged or untagged depending on the context it will be used in. A tagged COSE_Encrypt0 structure is identified by the CBOR tag TBD3. The CDDL fragment that represents this is: COSE_Encrypt0_Tagged = #6.993(COSE_Encrypt0) ; Replace 993 with TBD3 The COSE_Encrypt0 structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. ciphertext as described in Section 5.1. The CDDL fragment for COSE_Encrypt0 that corresponds to the above text is: COSE_Encrypt0 = [ Headers, ciphertext : bstr / nil, ] 5.3. How to encrypt and decrypt for AEAD Algorithms The encryption algorithm for AEAD algorithms is fairly simple. The first step is to create a consistent byte stream for the authenticated data structure. For this purpose, we use an Enc_structure. The Enc_structure is a CBOR array. The fields of the Enc_structure in order are: 1. A text string identifying the context of the authenticated data structure. The context string is: Schaad Expires April 21, 2017 [Page 25] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 "Encrypt0" for the content encryption of a COSE_Encrypt0 data structure. "Encrypt" for the first layer of a COSE_Encrypt data structure (i.e., for content encryption). "Enc_Recipient" for a recipient encoding to be placed in an COSE_Encrypt data structure. "Mac_Recipient" for a recipient encoding to be placed in a MACed message structure. "Rec_Recipient" for a recipient encoding to be placed in a recipient structure. 2. The protected attributes from the body structure encoded in a bstr type. If there are no protected attributes, a bstr of length zero is used. 3. The protected attributes from the application encoded in a bstr type. If this field is not supplied, it defaults to a zero length bstr. (See Section 4.3 for application guidance on constructing this field.) The CDDL fragment that describes the above text is: Enc_structure = [ context : "Encrypt" / "Encrypt0" / "Enc_Recipient" / "Mac_Recipient" / "Rec_Recipient", protected : empty_or_serialized_map, external_aad : bstr ] How to encrypt a message: 1. Create an Enc_structure and populate it with the appropriate fields. 2. Encode the Enc_structure to a byte stream (AAD), using the encoding described in Section 14. 3. Determine the encryption key (K). This step is dependent on the class of recipient algorithm being used. For: No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys Section 12.3, key wrap keys Section 12.2.1 or pre-shared secrets. Schaad Expires April 21, 2017 [Page 26] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Section 12.1.2 and Section 12.4.1. Other: The key is randomly or pseudo-randomly generated. 4. Call the encryption algorithm with K (the encryption key), P (the plain text) and AAD. Place the returned cipher text into the 'ciphertext' field of the structure. 5. For recipients of the message, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plain text. How to decrypt a message: 1. Create a Enc_structure and populate it with the appropriate fields. 2. Encode the Enc_structure to a byte stream (AAD), using the encoding described in Section 14. 3. Determine the decryption key. This step is dependent on the class of recipient algorithm being used. For: No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys Section 12.3, key wrap keys Section 12.2.1 or pre-shared secrets. Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Section 12.1.2 and Section 12.4.1. Other: The key is determined by decoding and decrypting one of the recipient structures. 4. Call the decryption algorithm with K (the decryption key to use), C (the cipher text) and AAD. Schaad Expires April 21, 2017 [Page 27] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 5.4. How to encrypt and decrypt for AE Algorithms How to encrypt a message: 1. Verify that the 'protected' field is empty. 2. Verify that there was no external additional authenticated data supplied for this operation. 3. Determine the encryption key. This step is dependent on the class of recipient algorithm being used. For: No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys Section 12.3, key wrap keys Section 12.2.1 or pre-shared secrets. Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Section 12.1.2 and Section 12.4.1. Other: The key is randomly generated. 4. Call the encryption algorithm with K (the encryption key to use) and the P (the plain text). Place the returned cipher text into the 'ciphertext' field of the structure. 5. For recipients of the message, recursively perform the encryption algorithm for that recipient, using K (the encryption key) as the plain text. How to decrypt a message: 1. Verify that the 'protected' field is empty. 2. Verify that there was no external additional authenticated data supplied for this operation. 3. Determine the decryption key. This step is dependent on the class of recipient algorithm being used. For: No Recipients: The key to be used is determined by the algorithm and key at the current layer. Examples are key transport keys Schaad Expires April 21, 2017 [Page 28] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 Section 12.3, key wrap keys Section 12.2.1 or pre-shared secrets. Direct Encryption and Direct Key Agreement: The key is determined by the key and algorithm in the recipient structure. The encryption algorithm and size of the key to be used are inputs into the KDF used for the recipient. (For direct, the KDF can be thought of as the identity operation.) Examples of these algorithms are found in Section 12.1.2 and Section 12.4.1. Other: The key is determined by decoding and decrypting one of the recipient structures. 4. Call the decryption algorithm with K (the decryption key to use), and C (the cipher text). 6. MAC Objects COSE supports two different MAC structures. COSE_MAC0 is used when a recipient structure is not needed because the key to be used is implicitly known. COSE_MAC is used for all other cases. These include a requirement for multiple recipients, the key being unknown, and a recipient algorithm of other than direct. In this section, we describe the structure and methods to be used when doing MAC authentication in COSE. This document allows for the use of all of the same classes of recipient algorithms as are allowed for encryption. When using MAC operations, there are two modes in which they can be used. The first is just a check that the content has not been changed since the MAC was computed. Any class of recipient algorithm can be used for this purpose. The second mode is to both check that the content has not been changed since the MAC was computed, and to use the recipient algorithm to verify who sent it. The classes of recipient algorithms that support this are those that use a pre- shared secret or do static-static key agreement (without the key wrap step). In both of these cases, the entity that created and sent the message MAC can be validated. (This knowledge of sender assumes that there are only two parties involved and you did not send the message to yourself.) The origination property can be obtained with both of the MAC message structures. Schaad Expires April 21, 2017 [Page 29] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 6.1. MACed Message with Recipients The multiple recipient MACed message uses two structures, the COSE_Mac structure defined in this section for carrying the body and the COSE_recipient structure (Section 5.1) to hold the key used for the MAC computation. Examples of MACed messages can be found in Appendix C.5. The MAC structure can be encoded either tagged or untagged depending on the context it will be used in. A tagged COSE_Mac structure is identified by the CBOR tag TBD4. The CDDL fragment that represents this is: COSE_Mac_Tagged = #6.994(COSE_Mac) ; Replace 994 with TBD4 The COSE_Mac structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. payload contains the serialized content to be MACed. If the payload is not present in the message, the application is required to supply the payload separately. The payload is wrapped in a bstr to ensure that it is transported without changes. If the payload is transported separately (i.e., detached content), then a nil CBOR value is placed in this location and it is the responsibility of the application to ensure that it will be transported without changes. tag contains the MAC value. recipients as described in Section 5.1. The CDDL fragment that represents the above text for COSE_Mac follows. COSE_Mac = [ Headers, payload : bstr / nil, tag : bstr, recipients :[+COSE_recipient] ] Schaad Expires April 21, 2017 [Page 30] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 6.2. MACed Messages with Implicit Key In this section, we describe the structure and methods to be used when doing MAC authentication for those cases where the recipient is implicitly known. The MACed message uses the COSE_Mac0 structure defined in this section for carrying the body. Examples of MACed messages with an implicit key can be found in Appendix C.6. The MAC structure can be encoded either tagged or untagged depending on the context it will be used in. A tagged COSE_Mac0 structure is identified by the CBOR tag TBD6. The CDDL fragment that represents this is: COSE_Mac0_Tagged = #6.996(COSE_Mac0) ; Replace 996 with TBD6 The COSE_Mac0 structure is a CBOR array. The fields of the array in order are: protected as described in Section 3. unprotected as described in Section 3. payload as described in Section 6.1. tag contains the MAC value. The CDDL fragment that corresponds to the above text is: COSE_Mac0 = [ Headers, payload : bstr / nil, tag : bstr, ] 6.3. How to compute and verify a MAC In order to get a consistent encoding of the data to be authenticated, the MAC_structure is used to have a canonical form. The MAC_structure is a CBOR array. The fields of the MAC_structure in order are: 1. A text string that identifies the structure that is being encoded. This string is "MAC" for the COSE_Mac structure. This string is "MAC0" for the COSE_Mac0 structure. Schaad Expires April 21, 2017 [Page 31] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 2. The protected attributes from the COSE_MAC structure. If there are no protected attributes, a zero length bstr is used. 3. The protected attributes from the application encoded as a bstr type. If this field is not supplied, it defaults to a zero length binary string. (See Section 4.3 for application guidance on constructing this field.) 4. The payload to be MAC-ed encoded in a bstr type. The payload is placed here independent of how it is transported. The CDDL fragment that corresponds to the above text is: MAC_structure = [ context : "MAC" / "MAC0", protected : empty_or_serialized_map, external_aad : bstr, payload : bstr ] The steps to compute a MAC are: 1. Create a MAC_structure and populate it with the appropriate fields. 2. Create the value ToBeMaced by encoding the MAC_structure to a byte stream, using the encoding described in Section 14. 3. Call the MAC creation algorithm passing in K (the key to use), alg (the algorithm to MAC with) and ToBeMaced (the value to compute the MAC on). 4. Place the resulting MAC in the 'tag' field of the COSE_Mac or COSE_Mac0 structure. 5. Encrypt and encode the MAC key for each recipient of the message. The steps to verify a MAC are: 1. Create a MAC_structure object and populate it with the appropriate fields. 2. Create the value ToBeMaced by encoding the MAC_structure to a byte stream, using the encoding described in Section 14. 3. Obtain the cryptographic key from one of the recipients of the message. Schaad Expires April 21, 2017 [Page 32] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 4. Call the MAC creation algorithm passing in K (the key to use), alg (the algorithm to MAC with) and ToBeMaced (the value to compute the MAC on). 5. Compare the MAC value to the 'tag' field of the COSE_Mac or COSE_Mac0 structure. 7. Key Objects A COSE Key structure is built on a CBOR map object. The set of common parameters that can appear in a COSE Key can be found in the IANA "COSE Key Common Parameters" registry (Section 16.5). Additional parameters defined for specific key types can be found in the IANA "COSE Key Type Parameters" registry (Section 16.6). A COSE Key Set uses a CBOR array object as its underlying type. The values of the array elements are COSE Keys. A Key Set MUST have at least one element in the array. Examples of Key Sets can be found in Appendix C.7. Each element in a key set MUST be processed independently. If one element in a key set is either malformed or uses a key that is not understood by an application, that key is ignored and the other keys are processed normally. The element "kty" is a required element in a COSE_Key map. The CDDL grammar describing COSE_Key and COSE_KeySet is: COSE_Key = { 1 => tstr / int, ; kty ? 2 => bstr, ; kid ? 3 => tstr / int, ; alg ? 4 => [+ (tstr / int) ], ; key_ops ? 5 => bstr, ; Base IV * label => values } COSE_KeySet = [+COSE_Key] 7.1. COSE Key Common Parameters This document defines a set of common parameters for a COSE Key object. Table 3 provides a summary of the parameters defined in this section. There are also parameters that are defined for specific key types. Key type specific parameters can be found in Section 13. Schaad Expires April 21, 2017 [Page 33] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 +---------+-------+----------------+------------+-------------------+ | name | label | CBOR type | registry | description | +---------+-------+----------------+------------+-------------------+ | kty | 1 | tstr / int | COSE Key | Identification of | | | | | Common | the key type | | | | | Parameters | | | | | | | | | alg | 3 | tstr / int | COSE | Key usage | | | | | Algorithm | restriction to | | | | | Values | this algorithm | | | | | | | | kid | 2 | bstr | | Key | | | | | | Identification | | | | | | value - match to | | | | | | kid in message | | | | | | | | key_ops | 4 | [+ (tstr/int)] | | Restrict set of | | | | | | permissible | | | | | | operations | | | | | | | | Base IV | 5 | bstr | | Base IV to be | | | | | | xor-ed with | | | | | | Partial IVs | +---------+-------+----------------+------------+-------------------+ Table 3: Key Map Labels kty: This parameter is used to identify the family of keys for this structure, and thus the set of key type specific parameters to be found. The set of values defined in this document can be found in Table 21. This parameter MUST be present in a key object. Implementations MUST verify that the key type is appropriate for the algorithm being processed. The key type MUST be included as part of the trust decision process. alg: This parameter is used to restrict the algorithm that is used with the key. If this parameter is present in the key structure, the application MUST verify that this algorithm matches the algorithm for which the key is being used. If the algorithms do not match, then this key object MUST NOT be used to perform the cryptographic operation. Note that the same key can be in a different key structure with a different or no algorithm specified, however this is considered to be a poor security practice. kid: This parameter is used to give an identifier for a key. The identifier is not structured and can be anything from a user provided string to a value computed on the public portion of the Schaad Expires April 21, 2017 [Page 34] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 key. This field is intended for matching against a 'kid' parameter in a message in order to filter down the set of keys that need to be checked. key_ops: This parameter is defined to restrict the set of operations that a key is to be used for. The value of the field is an array of values from Table 4. Algorithms define the values of key ops that are permitted to appear and are required for specific operations. The set of values matches that in [RFC7517] and [W3C.WebCrypto]. Base IV: This parameter is defined to carry the base portion of an IV. It is designed to be used with the partial IV header parameter defined in Section 3.1. This field provides the ability to associate a partial IV with a key that is then modified on a per message basis with the partial IV. Extreme care needs to be taken when using a Base IV in an application. Many encryption algorithms lose security if the same IV is used twice. If different keys are derived for each sender, using the same base IV with partial IVs starting at zero is likely to ensure that the IV would not be used twice for a single key. If different keys are derived for each sender, starting at the same base IV is likely to satisfy this condition. If the same key is used for multiple senders, then the application needs to provide for a method of dividing the IV space up between the senders. This could be done by providing a different base point to start from or a different partial IV to start with and restricting the number of messages to be sent before re-keying. Schaad Expires April 21, 2017 [Page 35] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 +---------+-------+-------------------------------------------------+ | name | value | description | +---------+-------+-------------------------------------------------+ | sign | 1 | The key is used to create signatures. Requires | | | | private key fields. | | | | | | verify | 2 | The key is used for verification of signatures. | | | | | | encrypt | 3 | The key is used for key transport encryption. | | | | | | decrypt | 4 | The key is used for key transport decryption. | | | | Requires private key fields. | | | | | | wrap | 5 | The key is used for key wrapping. | | key | | | | | | | | unwrap | 6 | The key is used for key unwrapping. Requires | | key | | private key fields. | | | | | | derive | 7 | The key is used for deriving keys. Requires | | key | | private key fields. | | | | | | derive | 8 | The key is used for deriving bits not to be | | bits | | used as a key. Requires private key fields. | | | | | | MAC | 9 | The key is used for creating MACs. | | create | | | | | | | | MAC | 10 | The key is used for validating MACs. | | verify | | | +---------+-------+-------------------------------------------------+ Table 4: Key Operation Values 8. Signature Algorithms There are two signature algorithm schemes. The first is signature with appendix. In this scheme, the message content is processed and a signature is produced, the signature is called the appendix. This is the scheme used by algorithms such as ECDSA and RSASSA-PSS. (In fact the SSA in RSASSA-PSS stands for Signature Scheme with Appendix.) The signature functions for this scheme are: signature = Sign(message content, key) valid = Verification(message content, key, signature) Schaad Expires April 21, 2017 [Page 36] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 The second scheme is signature with message recovery. (An example of such an algorithm is [PVSig].) In this scheme, the message content is processed, but part of it is included in the signature. Moving bytes of the message content into the signature allows for smaller signatures, the signature size is still potentially large, but the message content has shrunk. This has implications for systems implementing these algorithms and for applications that use them. The first is that the message content is not fully available until after a signature has been validated. Until that point the part of the message contained inside of the signature is unrecoverable. The second is that the security analysis of the strength of the signature is very much based on the structure of the message content. Messages that are highly predictable require additional randomness to be supplied as part of the signature process. In the worst case, it becomes the same as doing a signature with appendix. Finally, in the event that multiple signatures are applied to a message, all of the signature algorithms are going to be required to consume the same number of bytes of message content. This means that mixing of the different schemes in a single message is not supported, and if a recovery signature scheme is used, then the same amount of content needs to be consumed by all of the signatures. The signature functions for this scheme are: signature, message sent = Sign(message content, key) valid, message content = Verification(message sent, key, signature) Signature algorithms are used with the COSE_Signature and COSE_Sign1 structures. At this time, only signatures with appendixes are defined for use with COSE, however considerable interest has been expressed in using a signature with message recovery algorithm due to the effective size reduction that is possible. Implementations will need to keep this in mind for later possible integration. 8.1. ECDSA ECDSA [DSS] defines a signature algorithm using ECC. Implementations SHOULD use a deterministic version of ECDSA such as the one defined in [RFC6979]. The use of a deterministic signature algorithms allows for systems to avoid relying on random number generators in order to avoid generating the same value of 'k' (the per-message random value). Biased generation of the value be attacked and collisions will lead to leaked keys. It additionally allows for doing deterministic tests for the signature algorithm. The use of deterministic ECDSA does not lessen the need to to have good random number generation when creating the private key. Schaad Expires April 21, 2017 [Page 37] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 The ECDSA signature algorithm is parameterized with a hash function (h). In the event that the length of the hash function output is greater than the group of the key, the left-most bytes of the hash output are used. The algorithms defined in this document can be found in Table 5. +-------+-------+---------+------------------+ | name | value | hash | description | +-------+-------+---------+------------------+ | ES256 | -7 | SHA-256 | ECDSA w/ SHA-256 | | | | | | | ES384 | -35 | SHA-384 | ECDSA w/ SHA-384 | | | | | | | ES512 | -36 | SHA-512 | ECDSA w/ SHA-512 | +-------+-------+---------+------------------+ Table 5: ECDSA Algorithm Values This document defines ECDSA to work only with the curves P-256, P-384 and P-521. This document requires that the curves be encoded using the 'EC2' (2 coordinate Elliptic Curve) key type. Implementations need to check that the key type and curve are correct when creating and verifying a signature. Other documents can define it to work with other curves and points in the future. In order to promote interoperability, it is suggested that SHA-256 be used only with curve P-256, SHA-384 be used only with curve P-384 and SHA-512 be used with curve P-521. This is aligned with the recommendation in Section 4 of [RFC5480]. The signature algorithm results in a pair of integers (R, S). These integers will the same length as length of the key used for the signature process. The signature is encoded by converting the integers into byte strings of the same length as the key size. The length is rounded up to the nearest byte and is left padded with zero bits to get to the correct length. The two integers are then concatenated together to form a byte string that is the resulting signature. Using the function defined in [I-D.moriarty-pkcs1] the signature is: Signature = I2OSP(R, n) | I2OSP(S, n) where n = ceiling(key_length / 8) When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'EC2'. Schaad Expires April 21, 2017 [Page 38] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 o If the 'alg' field is present, it MUST match the ECDSA signature algorithm being used. o If the 'key_ops' field is present, it MUST include 'sign' when creating an ECDSA signature. o If the 'key_ops' field is present, it MUST include 'verify' when verifying an ECDSA signature. 8.1.1. Security Considerations The security strength of the signature is no greater than the minimum of the security strength associated with the bit length of the key and the security strength of the hash function. Note: Use of this technique is a good idea even when good random number generation exists. Doing so both reduces the possibility of having the same value of 'k' in two signature operations and allows for reproducible signature values, which helps testing. There are two substitution attacks that can theoretically be mounted against the ECDSA signature algorithm. o Changing the curve used to validate the signature: If one changes the curve used to validate the signature, then potentially one could have a two messages with the same signature each computed under a different curve. The only requirement on the new curve is that its order be the same as the old one and it be acceptable to the client. An example would be to change from using the curve secp256r1 (aka P-256) to using secp256k1. (Both are 256 bit curves.) We current do not have any way to deal with this version of the attack except to restrict the overall set of curves that can be used. o Change the hash function used to validate the signature: If one has either two different hash functions of the same length, or one can truncate a hash function down, then one could potentially find collisions between the hash functions rather than within a single hash function. (For example, truncating SHA-512 to 256 bits might collide with a SHA-256 bit hash value.) As the hash algorithm is part of the signature algorithm identifier, this attack is mitigated by including signature algorithm identifier in the protected header. Schaad Expires April 21, 2017 [Page 39] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 8.2. Edwards-curve Digital Signature Algorithms (EdDSA) [I-D.irtf-cfrg-eddsa] describes the elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). In that document, the signature algorithm is instantiated using parameters for edwards25519 and edwards448 curves. The document additionally describes two variants of the EdDSA algorithm: Pure EdDSA, where no hash function is applied to the content before signing and, HashEdDSA where a hash function is applied to the content before signing and the result of that hash function is signed. For the EdDSA, the content to be signed (either the message or the pre-hash value) is processed twice inside of the signature algorithm. For use with COSE, only the pure EdDSA version is used. This is because it is not expected that extremely large contents are going to be needed and, based on the arrangement of the message structure, the entire message is going to need to be held in memory in order to create or verify a signature. This means that there does not appear to be a need to be able to do block updates of the hash, followed by eliminating the message from memory. Applications can provide the same features by defining the content of the message as a hash value and transporting the COSE object (with the hash value) and the content as separate items. The algorithms defined in this document can be found in Table 6. A single signature algorithm is defined, which can be used for multiple curves. +-------+-------+-------------+ | name | value | description | +-------+-------+-------------+ | EdDSA | -8 | EdDSA | +-------+-------+-------------+ Table 6: EdDSA Algorithm Values [I-D.irtf-cfrg-eddsa] describes the method of encoding the signature value. When using a COSE key for this algorithm the following checks are made: o The 'kty' field MUST be present and it MUST be 'OKP' (Octet Key Pair). o The 'crv' field MUST be present, and it MUST be a curve defined for this signature algorithm. o If the 'alg' field is present, it MUST match 'EdDSA'. Schaad Expires April 21, 2017 [Page 40] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 o If the 'key_ops' field is present, it MUST include 'sign' when creating an EdDSA signature. o If the 'key_ops' field is present, it MUST include 'verify' when verifying an EdDSA signature. 8.2.1. Security Considerations How public values are computed is not the same when looking at EdDSA and ECDH, for this reason they should not be used with the other algorithm. If batch signature verification is performed, a well-seeded cryptographic random number generator is REQUIRED. Signing and non- batch signature verification are deterministic operations and do not need random numbers of any kind. 9. Message Authentication (MAC) Algorithms Message Authentication Codes (MACs) provide data authentication and integrity protection. They provide either no or very limited data origination. A MAC, for example, be used to prove the identity of the sender to a third party. MACs use the same scheme as signature with appendix algorithms. The message content is processed and an authentication code is produced. The authentication code is frequently called a tag. The MAC functions are: tag = MAC_Create(message content, key) valid = MAC_Verify(message content, key, tag) MAC algorithms can be based on either a block cipher algorithm (i.e., AES-MAC) or a hash algorithm (i.e., HMAC). This document defines a MAC algorithm using each of these constructions. MAC algorithms are used in the COSE_Mac and COSE_Mac0 structures. 9.1. Hash-based Message Authentication Codes (HMAC) The Hash-based Message Authentication Code algorithm (HMAC) [RFC2104][RFC4231] was designed to deal with length extension attacks. The algorithm was also designed to allow for new hash algorithms to be directly plugged in without changes to the hash function. The HMAC design process has been shown as solid since, while the security of hash algorithms such as MD5 has decreased over Schaad Expires April 21, 2017 [Page 41] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 time, the security of HMAC combined with MD5 has not yet been shown to be compromised [RFC6151]. The HMAC algorithm is parameterized by an inner and outer padding, a hash function (h), and an authentication tag value length. For this specification, the inner and outer padding are fixed to the values set in [RFC2104]. The length of the authentication tag corresponds to the difficulty of producing a forgery. For use in constrained environments, we define a set of HMAC algorithms that are truncated. There are currently no known issues with truncation, however the security strength of the message tag is correspondingly reduced in strength. When truncating, the left-most tag length bits are kept and transmitted. The algorithms defined in this document can be found in Table 7. +-----------+-------+---------+----------+--------------------------+ | name | value | Hash | Tag | description | | | | | Length | | +-----------+-------+---------+----------+--------------------------+ | HMAC | 4 | SHA-256 | 64 | HMAC w/ SHA-256 | | 256/64 | | | | truncated to 64 bits | | | | | | | | HMAC | 5 | SHA-256 | 256 | HMAC w/ SHA-256 | | 256/256 | | | | | | | | | | | | HMAC | 6 | SHA-384 | 384 | HMAC w/ SHA-384 | | 384/384 | | | | | | | | | | | | HMAC | 7 | SHA-512 | 512 | HMAC w/ SHA-512 | | 512/512 | | | | | +-----------+-------+---------+----------+--------------------------+ Table 7: HMAC Algorithm Values Some recipient algorithms carry the key while others derive a key from secret data. For those algorithms that carry the key (such as AES-KeyWrap), the size of the HMAC key SHOULD be the same size as the underlying hash function. For those algorithms that derive the key (such as ECDH), the derived key MUST be the same size as the underlying hash function. When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'Symmetric'. Schaad Expires April 21, 2017 [Page 42] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 o If the 'alg' field is present, it MUST match the HMAC algorithm being used. o If the 'key_ops' field is present, it MUST include 'MAC create' when creating an HMAC authentication tag. o If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an HMAC authentication tag. Implementations creating and validating MAC values MUST validate that the key type, key length, and algorithm are correct and appropriate for the entities involved. 9.1.1. Security Considerations HMAC has proved to be resistant to attack even when used with weakened hash algorithms. The current best known attack appears is to brute force the key. This means that key size is going to be directly related to the security of an HMAC operation. 9.2. AES Message Authentication Code (AES-CBC-MAC) AES-CBC-MAC is defined in [MAC]. (Note this is not the same algorithm as AES-CMAC [RFC4493]). AES-CBC-MAC is parameterized by the key length, the authentication tag length and the IV used. For all of these algorithms, the IV is fixed to all zeros. We provide an array of algorithms for various key lengths and tag lengths. The algorithms defined in this document are found in Table 8. Schaad Expires April 21, 2017 [Page 43] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 +-------------+-------+----------+----------+-----------------------+ | name | value | key | tag | description | | | | length | length | | +-------------+-------+----------+----------+-----------------------+ | AES-MAC | 14 | 128 | 64 | AES-MAC 128 bit key, | | 128/64 | | | | 64-bit tag | | | | | | | | AES-MAC | 15 | 256 | 64 | AES-MAC 256 bit key, | | 256/64 | | | | 64-bit tag | | | | | | | | AES-MAC | 25 | 128 | 128 | AES-MAC 128 bit key, | | 128/128 | | | | 128-bit tag | | | | | | | | AES-MAC | 26 | 256 | 128 | AES-MAC 256 bit key, | | 256/128 | | | | 128-bit tag | +-------------+-------+----------+----------+-----------------------+ Table 8: AES-MAC Algorithm Values Keys may be obtained either from a key structure or from a recipient structure. Implementations creating and validating MAC values MUST validate that the key type, key length and algorithm are correct and appropriate for the entities involved. When using a COSE key for this algorithm, the following checks are made: o The 'kty' field MUST be present and it MUST be 'Symmetric'. o If the 'alg' field is present, it MUST match the AES-MAC algorithm being used. o If the 'key_ops' field is present, it MUST include 'MAC create' when creating an AES-MAC authentication tag. o If the 'key_ops' field is present, it MUST include 'MAC verify' when verifying an AES-MAC authentication tag. 9.2.1. Security Considerations A number of attacks exist against CBC-MAC that need to be considered. - o A single key must only be used for messages of a fixed and known length. If this is not the case, an attacker will be able to generate a message with a valid tag given two message and tag pairs. This can be addressed by using different keys for different length messages. The current structure mitigates this Schaad Expires April 21, 2017 [Page 44] Internet-Draft CBOR Object Signing and Encryption (COSE) October 2016 problem, as a specific encoding structure that includes lengths is built and signed. (CMAC also addresses this issue.) o When using CBC mode, if the same key is used for both encryption and authentication operations, an attacker can produce messages with a valid authentication code. o If the IV can be modified, then messages can be forged. This is addressed by fixing the IV to all zeros. 10. Content Encryption Algorithms Content Encryption Algorithms provide data confidentiality for potentially large blocks of data using a symmetric key. They provide integrity on the data that was encrypted, however they provide either no or very limited data origination. (One cannot, for example, be used to prove the identity of the sender to a third party.) The ability to provide data origination is linked to how the CEK is obtained. COSE restricts the set of legal content encryption algorithms to those that support authentication both of the content and additional data. The encryption process will generate some type of authentication value, but that value may be either explicit or implicit in terms of the algorithm definition. For simplicity sake, the authentication code will normally be defined as being appended to the cipher text stream. The encryption functions are: ciphertext = Encrypt(message content, key, additional data) valid, message content = Decrypt(cipher text, key, additional data) Most AEAD algorithms are logically defined as returning the message content only if the decryption is valid. Many but not all implementations will follow this convention. The message content MUST NOT be used if the decryption does not validate. These algorithms are used in COSE_Encrypt and COSE_Encrypt0. 10.1. AES GCM The GCM mode is a generic authenticated encryption block cipher mode defined in [AES-GCM]. The GCM mode is combined with the AES block encryption algorithm to define an AEAD cipher. The GCM mode is parameterized by the size of the authentication tag and the size of the nonce. This document fixes the size of the nonce at 96 bits. The size of the authentication tag is limited to a small Schaad Expires April 21, 2017 [Page 45]Waiting for AD Go-Ahead::External Party from Waiting for Writeup |
2020-10-01
|
19 | Alvaro Retana | Ballot writeup was changed |
2020-10-01
|
19 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2020-09-28
|
19 | Brian Trammell | Request for Last Call review by TSVART Completed: Ready with Issues. Reviewer: Brian Trammell. Sent review to list. |
2020-09-24
|
19 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2020-09-24
|
19 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Scott Kelly |
2020-09-22
|
19 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2020-09-22
|
19 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2020-09-21
|
19 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Brian Trammell |
2020-09-21
|
19 | Wesley Eddy | Request for Last Call review by TSVART is assigned to Brian Trammell |
2020-09-18
|
19 | John Scudder | New version available: draft-ietf-idr-tunnel-encaps-19.txt |
2020-09-18
|
19 | (System) | New version accepted (logged-in submitter: John Scudder) |
2020-09-18
|
19 | John Scudder | Uploaded new revision |
2020-09-18
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Gyan Mishra |
2020-09-18
|
18 | Jean Mahoney | Request for Last Call review by GENART is assigned to Gyan Mishra |
2020-09-17
|
18 | Min Ye | Request for Last Call review by RTGDIR is assigned to Harish Sitaraman |
2020-09-17
|
18 | Min Ye | Request for Last Call review by RTGDIR is assigned to Harish Sitaraman |
2020-09-17
|
18 | Alvaro Retana | Requested Last Call review by RTGDIR |
2020-09-17
|
18 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2020-09-17
|
18 | Cindy Morgan | The following Last Call announcement was sent out (ends 2020-10-01): From: The IESG To: IETF-Announce CC: idr@ietf.org, Susan Hares , aretana.ietf@gmail.com, John Scudder … The following Last Call announcement was sent out (ends 2020-10-01): From: The IESG To: IETF-Announce CC: idr@ietf.org, Susan Hares , aretana.ietf@gmail.com, John Scudder , shares@ndzh.com, draft-ietf-idr-tunnel-encaps@ietf.org, idr-chairs@ietf.org Reply-To: last-call@ietf.org Sender: Subject: Last Call: (The BGP Tunnel Encapsulation Attribute) to Proposed Standard The IESG has received a request from the Inter-Domain Routing WG (idr) to consider the following document: - 'The BGP Tunnel Encapsulation Attribute' 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 last-call@ietf.org mailing lists by 2020-10-01. 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 RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that use the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional Tunnel Types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. This document obsoletes RFC 5512. Since RFCs 5566 and 5640 rely on RFC 5512, they are likewise obsoleted. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/ 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-nvo3-vxlan-gpe: Generic Protocol Extension for VXLAN (VXLAN-GPE) (None - IETF stream) |
2020-09-17
|
18 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2020-09-17
|
18 | Alvaro Retana | Last call was requested |
2020-09-17
|
18 | Alvaro Retana | Ballot approval text was generated |
2020-09-17
|
18 | Alvaro Retana | Ballot writeup was generated |
2020-09-17
|
18 | Alvaro Retana | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2020-09-17
|
18 | Alvaro Retana | Last call announcement was generated |
2020-09-11
|
18 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-09-11
|
18 | John Scudder | New version available: draft-ietf-idr-tunnel-encaps-18.txt |
2020-09-11
|
18 | (System) | New version accepted (logged-in submitter: John Scudder) |
2020-09-11
|
18 | John Scudder | Uploaded new revision |
2020-08-04
|
17 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup |
2020-08-04
|
17 | Alvaro Retana | Notification list changed to John Scudder <jgs@juniper.net>, aretana.ietf@gmail.com, Susan Hares <shares@ndzh.com> from John Scudder <jgs@juniper.net>, aretana.ietf@gmail.com |
2020-08-04
|
17 | Alvaro Retana | Document shepherd changed to Susan Hares |
2020-07-17
|
17 | John Scudder | New version available: draft-ietf-idr-tunnel-encaps-17.txt |
2020-07-17
|
17 | (System) | Forced post of submission |
2020-07-17
|
17 | (System) | Request for posting confirmation emailed to previous authors: Gunter Van de Velde , Keyur Patel , John Scudder , Srihari Ramachandra |
2020-07-17
|
17 | John Scudder | Uploaded new revision |
2020-07-13
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2020-07-13
|
16 | John Scudder | New version available: draft-ietf-idr-tunnel-encaps-16.txt |
2020-07-13
|
16 | (System) | New version approved |
2020-07-13
|
16 | (System) | Request for posting confirmation emailed to previous authors: Keyur Patel , idr-chairs@ietf.org, Gunter Van de Velde , Srihari Ramachandra |
2020-07-13
|
16 | John Scudder | Uploaded new revision |
2020-02-21
|
15 | Alvaro Retana | === AD Review of draft-ietf-idr-tunnel-encaps-15 === https://mailarchive.ietf.org/arch/msg/idr/S1nyz1sewA_Xqf63W_vz8c4L8Z0 |
2020-02-21
|
15 | Alvaro Retana | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2020-01-17
|
15 | Alvaro Retana | IESG state changed to AD Evaluation from Publication Requested |
2020-01-17
|
15 | Alvaro Retana | Notification list changed to John Scudder <jgs@juniper.net>, aretana.ietf@gmail.com from John Scudder <jgs@juniper.net> |
2019-12-01
|
15 | Keyur Patel | New version available: draft-ietf-idr-tunnel-encaps-15.txt |
2019-12-01
|
15 | (System) | New version approved |
2019-12-01
|
15 | (System) | Request for posting confirmation emailed to previous authors: Srihari Ramachandra , Gunter Van de Velde , Keyur Patel |
2019-12-01
|
15 | Keyur Patel | Uploaded new revision |
2019-10-10
|
14 | John Scudder | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? Proposed Standard. The document defines procedures and operation for BGP. Further, it makes requests to IANA and obsoletes a PS RFC. The header indicates Standards Track. (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 RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document went through two full WGLCs. The first one, for draft -04, generated a substantial amount of discussion. It concluded on June 9, 2017 without consensus to proceed, but did result in extensive review and discussion, with all points that were raised either being reflected in the later versions of the draft, or otherwise resolved. The chairs' summary of the WGLC is at https://www.ietf.org/mail-archive/web/idr/current/msg18246.html The second one, for draft -07 (with cc OSPF and BESS since they both normatively reference the draft) concluded October 20, 2017 with some support and no dissent. Given the extensive review and discussion as part of the first WGLC, the chairs were satisified with this outcome. Subsequent to the second WGLC, further issues were reported by implementors (this is why IDR has an implementation requirement!). Some issues also were found by the document shepherd in the course of preparing this report. The related updates brought the draft version up to -12. We had an "additional comment period" to allow the WG to raise any concerns related to the changes, the thread can be found at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=3_Fmk0Ble3VaAaDzAqt7heOpfc4 Finally, an editorial issue was surfaced in the course of a WG discussion about a number of different SD-WAN related proposals. A number of readers considered the use of the term "remote tunnel endpoint" confusing since it wasn't clear from what point of view the tunnel was considered "remote". That discussion can be found, in part, at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=vPmpkz7tPWfo0laWHRtLayMF5ZA Although it sprawled across a few threads, this is the one that concludes them. The authors eventually decided to revise their terminology to change "remote tunnel endpoint" to "tunnel egress endpoint" in -13; this settled the issue. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The IDR implementation report page is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The document shepherd is John Scudder. The responsible AD is Alvaro Retana. (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 read the draft in detail several times during the course of its development, and worked with the authors to address comments. This includes a review of the current version. (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. Authors have so confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. N/A (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? Considering the amount of conversation on the mailing list and at the in-person meetings, discussed above under "working group summary", I'd say it has broad consensus. (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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Note that the idnits error about an IPv4 address is bogus, idnits is confusing a section reference (9.1.2.1) for an IP address, possibly because of where the line break is? Idnits complains about downrefs. See answer to (15). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe. The NVO3 chairs state that their WG plans to advance this draft following advancement of Geneve, and that Geneve has been sent to the IESG for advancement. So, it appears GPE will be ready for advancement soon. (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. o RFC 7348 ("Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks") o RFC 7637 ("NVGRE: Network Virtualization Using Generic Routing Encapsulation") o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN") The first two are Informational, ISE stream documents. The relevant case in RFC 3967 is: o A standards document may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs. draft-ietf-nvo3-vxlan-gpe which currently lists its intended status as "informational"; the authors and NVO3 chairs confirm this is correct. It's my opinion that this downref is ok in the spirit of the above, even though the draft is an IETF product. Given that the tunnel-encaps specification is extensible, it seems overly restrictive to prevent it from being extended to signal a particular encapsulation just because that encapsulation is specified in an informational document. Importantly, the "informational" references, while normative in the sense that the specification can't be fully understood without understanding the references as well, are NOT required for the core elements of the specification. It would be possible to produce an implementation of the specification that complies and interoperates but doesn't support any of the encapsulations in the downref specs. (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. Yes, RFC 5512 is obsoleted and the reasons adequately discussed. (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). Confirmed. (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. N/A (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. N/A |
2019-10-10
|
14 | John Scudder | Responsible AD changed to Alvaro Retana |
2019-10-10
|
14 | John Scudder | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2019-10-10
|
14 | John Scudder | IESG state changed to Publication Requested from I-D Exists |
2019-10-10
|
14 | John Scudder | IESG process started in state Publication Requested |
2019-10-10
|
14 | John Scudder | As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated … As required by RFC 4858, this is the current template for the Document Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (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? Proposed Standard. The document defines procedures and operation for BGP. Further, it makes requests to IANA and obsoletes a PS RFC. The header indicates Standards Track. (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 RFC 5512 defines a BGP Path Attribute known as the "Tunnel Encapsulation Attribute". This attribute allows one to specify a set of tunnels. For each such tunnel, the attribute can provide the information needed to create the tunnel and the corresponding encapsulation header. The attribute can also provide information that aids in choosing whether a particular packet is to be sent through a particular tunnel. RFC 5512 states that the attribute is only carried in BGP UPDATEs that have the "Encapsulation Subsequent Address Family (Encapsulation SAFI)". This document deprecates the Encapsulation SAFI (which has never been used in production), and specifies semantics for the attribute when it is carried in UPDATEs of certain other SAFIs. This document adds support for additional tunnel types, and allows a remote tunnel endpoint address to be specified for each tunnel. This document also provides support for specifying fields of any inner or outer encapsulations that may be used by a particular tunnel. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? The document went through two full WGLCs. The first one, for draft -04, generated a substantial amount of discussion. It concluded on June 9, 2017 without consensus to proceed, but did result in extensive review and discussion, with all points that were raised either being reflected in the later versions of the draft, or otherwise resolved. The chairs' summary of the WGLC is at https://www.ietf.org/mail-archive/web/idr/current/msg18246.html The second one, for draft -07 (with cc OSPF and BESS since they both normatively reference the draft) concluded October 20, 2017 with some support and no dissent. Given the extensive review and discussion as part of the first WGLC, the chairs were satisified with this outcome. Subsequent to the second WGLC, further issues were reported by implementors (this is why IDR has an implementation requirement!). Some issues also were found by the document shepherd in the course of preparing this report. The related updates brought the draft version up to -12. We had an "additional comment period" to allow the WG to raise any concerns related to the changes, the thread can be found at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=3_Fmk0Ble3VaAaDzAqt7heOpfc4 Finally, an editorial issue was surfaced in the course of a WG discussion about a number of different SD-WAN related proposals. A number of readers considered the use of the term "remote tunnel endpoint" confusing since it wasn't clear from what point of view the tunnel was considered "remote". That discussion can be found, in part, at https://mailarchive.ietf.org/arch/browse/idr/?gbt=1&index=vPmpkz7tPWfo0laWHRtLayMF5ZA Although it sprawled across a few threads, this is the one that concludes them. The authors eventually decided to revise their terminology to change "remote tunnel endpoint" to "tunnel egress endpoint" in -13; this settled the issue. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? The IDR implementation report page is at https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-tunnel-encaps%20implementations Personnel Who is the Document Shepherd? Who is the Responsible Area Director? The document shepherd is John Scudder. The responsible AD is Alvaro Retana. (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 read the draft in detail several times during the course of its development, and worked with the authors to address comments. This includes a review of the current version. (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. Authors have so confirmed. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. N/A (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? Considering the amount of conversation on the mailing list and at the in-person meetings, discussed above under "working group summary", I'd say it has broad consensus. (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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Note that the idnits error about an IPv4 address is bogus, idnits is confusing a section reference (9.1.2.1) for an IP address, possibly because of where the line break is? Idnits complains about downrefs. See answer to (15). (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. N/A (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? Yes, there is a reference to draft-ietf-nvo3-vxlan-gpe. The NVO3 chairs state that their WG plans to advance this draft following advancement of Geneve, and that Geneve has been sent to the IESG for advancement. So, it appears GPE will be ready for advancement soon. (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. o RFC 7348 ("Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks") o RFC 7637 ("NVGRE: Network Virtualization Using Generic Routing Encapsulation") o draft-ietf-nvo3-vxlan-gpe ("Generic Protocol Extension for VXLAN") The first two are Informational, ISE stream documents. The relevant case in RFC 3967 is: o A standards document may need to refer to a proprietary protocol, and the IETF normally documents proprietary protocols using informational RFCs. draft-ietf-nvo3-vxlan-gpe which currently lists its intended status as "informational"; the authors and NVO3 chairs confirm this is correct. It's my opinion that this downref is ok in the spirit of the above, even though the draft is an IETF product. Given that the tunnel-encaps specification is extensible, it seems overly restrictive to prevent it from being extended to signal a particular encapsulation just because that encapsulation is specified in an informational document. Importantly, the "informational" references, while normative in the sense that the specification can't be fully understood without understanding the references as well, are NOT required for the core elements of the specification. It would be possible to produce an implementation of the specification that complies and interoperates but doesn't support any of the encapsulations in the downref specs. (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. Yes, RFC 5512 is obsoleted and the reasons adequately discussed. (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). Confirmed. (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. N/A (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. N/A |
2019-09-30
|
14 | Keyur Patel | New version available: draft-ietf-idr-tunnel-encaps-14.txt |
2019-09-30
|
14 | (System) | New version approved |
2019-09-30
|
14 | (System) | Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Srihari Ramachandra , Eric Rosen , Gunter Van de Velde , Keyur Patel |
2019-09-30
|
14 | Keyur Patel | Uploaded new revision |
2019-07-22
|
13 | Keyur Patel | New version available: draft-ietf-idr-tunnel-encaps-13.txt |
2019-07-22
|
13 | (System) | New version approved |
2019-07-22
|
13 | (System) | Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Srihari Ramachandra , Eric Rosen , Gunter Van de Velde , Keyur Patel |
2019-07-22
|
13 | Keyur Patel | Uploaded new revision |
2019-05-20
|
12 | Keyur Patel | New version available: draft-ietf-idr-tunnel-encaps-12.txt |
2019-05-20
|
12 | (System) | New version approved |
2019-05-20
|
12 | (System) | Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Gunter Van de Velde , Eric Rosen , Keyur Patel |
2019-05-20
|
12 | Keyur Patel | Uploaded new revision |
2019-02-22
|
11 | Keyur Patel | New version available: draft-ietf-idr-tunnel-encaps-11.txt |
2019-02-22
|
11 | (System) | New version approved |
2019-02-22
|
11 | (System) | Request for posting confirmation emailed to previous authors: Gunter Van de Velde , Eric Rosen , Keyur Patel |
2019-02-22
|
11 | Keyur Patel | Uploaded new revision |
2019-02-21
|
10 | (System) | Document has expired |
2018-08-20
|
10 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-10.txt |
2018-08-20
|
10 | (System) | New version approved |
2018-08-20
|
10 | (System) | Request for posting confirmation emailed to previous authors: Gunter Van de Velde , Eric Rosen , Keyur Patel |
2018-08-20
|
10 | Eric Rosen | Uploaded new revision |
2018-03-22
|
09 | John Scudder | Notification list changed to John Scudder <jgs@juniper.net> |
2018-03-22
|
09 | John Scudder | Document shepherd changed to John Scudder |
2018-02-28
|
09 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-09.txt |
2018-02-28
|
09 | (System) | New version approved |
2018-02-28
|
09 | (System) | Request for posting confirmation emailed to previous authors: Gunter Van de Velde , Eric Rosen , Keyur Patel |
2018-02-28
|
09 | Eric Rosen | Uploaded new revision |
2018-01-26
|
08 | Alvaro Retana | Changed consensus to Yes from Unknown |
2018-01-26
|
08 | Alvaro Retana | Intended Status changed to Proposed Standard from None |
2018-01-11
|
08 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-08.txt |
2018-01-11
|
08 | (System) | New version approved |
2018-01-11
|
08 | (System) | Request for posting confirmation emailed to previous authors: Gunter Van de Velde , Eric Rosen , Keyur Patel |
2018-01-11
|
08 | Eric Rosen | Uploaded new revision |
2017-10-20
|
07 | John Scudder | From: "John G. Scudder" Subject: Re: [Idr] [OSPF] WGLC for draft-ietf-idr-tunnel-encaps-07 Date: October 20, 2017 at 9:55:14 PM GMT+3 To: idr@ietf.org Cc: draft-ietf-idr-tunnel-encaps@ietf.org This WGLC … From: "John G. Scudder" Subject: Re: [Idr] [OSPF] WGLC for draft-ietf-idr-tunnel-encaps-07 Date: October 20, 2017 at 9:55:14 PM GMT+3 To: idr@ietf.org Cc: draft-ietf-idr-tunnel-encaps@ietf.org This WGLC is concluded. Based on feedback received during this and the previous WGLC, we will forward the document for publication as RFC. If anyone is willing to volunteer as shepherd, please let me know. (It's a useful way to gain insight into how the sausage is made, worth your while if you're so inclined.) Thanks, --John |
2017-10-20
|
07 | John Scudder | IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call |
2017-10-06
|
07 | John Scudder | IETF WG state changed to In WG Last Call from WG Document |
2017-07-18
|
07 | Jie Dong | Added to session: IETF-99: idr Thu-0930 |
2017-07-17
|
07 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-07.txt |
2017-07-17
|
07 | (System) | New version approved |
2017-07-17
|
07 | (System) | Request for posting confirmation emailed to previous authors: Gunter Van de Velde , Eric Rosen , Keyur Patel |
2017-07-17
|
07 | Eric Rosen | Uploaded new revision |
2017-06-14
|
06 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-06.txt |
2017-06-14
|
06 | (System) | New version approved |
2017-06-14
|
06 | (System) | Request for posting confirmation emailed to previous authors: Gunter Van de Velde , Eric Rosen , Keyur Patel |
2017-06-14
|
06 | Eric Rosen | Uploaded new revision |
2017-05-23
|
05 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-05.txt |
2017-05-23
|
05 | (System) | New version approved |
2017-05-23
|
05 | (System) | Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Keyur Patel , Eric Rosen , Gunter Van de Velde |
2017-05-23
|
05 | Eric Rosen | Uploaded new revision |
2017-04-14
|
04 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-04.txt |
2017-04-14
|
04 | (System) | New version approved |
2017-04-14
|
04 | (System) | Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, Keyur Patel , Eric Rosen , Gunter Van de Velde |
2017-04-14
|
04 | Eric Rosen | Uploaded new revision |
2016-11-21
|
03 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-03.txt |
2016-11-21
|
03 | (System) | New version approved |
2016-11-21
|
03 | (System) | Request for posting confirmation emailed to previous authors: idr-chairs@ietf.org, "Gunter Van de Velde" , "Keyur Patel" , "Eric Rosen" |
2016-11-21
|
03 | Eric Rosen | Uploaded new revision |
2016-10-18
|
02 | Susan Hares | This document now replaces draft-rosen-idr-tunnel-encaps, draft-vandevelde-idr-remote-next-hop instead of draft-rosen-idr-tunnel-encaps |
2016-05-31
|
02 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-02.txt |
2015-12-21
|
01 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-01.txt |
2015-08-19
|
00 | (System) | This document now replaces draft-rosen-idr-tunnel-encaps instead of None |
2015-08-19
|
00 | Eric Rosen | New version available: draft-ietf-idr-tunnel-encaps-00.txt |