-04 posted

draft-ymbk-idr-l3nd.xml

@@ -11,7 +11,7 @@
 <?rfc tocindent="yes"?>
 <?rfc tocompact="yes"?>
 
-<rfc consensus="yes" category="std" submissionType="IETF" docName="draft-ymbk-idr-l3nd-03" ipr="trust200902">
+<rfc consensus="yes" category="std" submissionType="IETF" docName="draft-ymbk-idr-l3nd-04" ipr="trust200902">
 
 <front>
 
@@ -389,7 +389,7 @@
   <section anchor="hello" title="HELLO">
 
 <!--
-    protocol "Version = 0:8,PDU Type = 0:8,Payload Length = 3:32,Flags:8,Port:16"
+    protocol "Version = 0:8,PDU Type = 0:8,Payload Length = 4:32,Transport:8,Flags:8,Port:16"
 -->
 
     <figure>
@@ -397,27 +397,18 @@
  0                   1                   2                   3  
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|  Version = 0  |  PDU Type = 0 |      Payload Length = 3       ~
+|  Version = 0  |  PDU Type = 0 |       Payload Length = 4      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-~                               |     Flags     |      Port     ~
+|                               |   Transport   |     Flags     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-~               |
+|              Port             |
-+-+-+-+-+-+-+-+-+
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-Flags (bit):
-   0 - 0 Raw TCP, 1 TLS
-   1 - 0 Self-Signed Cert for TLS, 1 CA-based
         </artwork>
       </figure>
 
-    <t>The Payload Length is 3 to cover the Flags and Port fields.</t>
+    <t>The Payload Length is 4 to cover the Transport, Flags, and Port
+    fields.</t>
 
-    <t>The Port is the two octet TCP Port Number (default is TBD3) on
-    which the HELLO sender MUST have a waiting TLS/TCP (as specified in
-    Flags) server listening.  Though the IANA assigned well-known port
-    SHOULD be used, this field allows configuration of alternate
-    ports.</t>
-      
     <t>The IPv4 UDP packets are sent to the IPv4 link local multicast
     address (TBD1) and the IPv6 UDP packets are sent to an IPv6 link
     Local multicast address (TBD2).  See <xref target="dhello"/> for why
@@ -447,7 +438,8 @@ Flags (bit):
     and network noise and adjust the inter-HELLO timer accordingly.</t>
 
     <t>By default, GTSM, <xref target="RFC5082"/>, SHOULD be enabled to
-    test that a received HELLO MUST be on the local link.  It MAY be
+    test that a received HELLO MUST be on the local link; thus leaving
+    no middle on which a monkey in the middle might stand.  It MAY be
     disabled by configuration.  GTSM check failures SHOULD be logged,
     though with rate limiting to keep from overwhelming logs.</t>
 
@@ -466,15 +458,74 @@ Flags (bit):
     <t>A device with a TLS/TCP listener SHOULD log or otherwise report
     repeated failed inbound attempts.</t>
 
+    <section anchor="transport" title="Transport">
+
+      <t>The Transport signals the type of transport security for the
+      session.</t>
+
+      <t>The actual transport options are actually pre-configured in the
+      devices by provisioning, as most require certificates etc.  It is
+      best to think of this field as in-band signaling to conform the
+      correctness of the pre-configurations.  Any disagreements MUST BE
+      considered to indicate an error condition and brought to the
+      attention of the operator.</t>
+
+      <t>The Transport field is an enumeration with the following values:
+	<list style="hanging">
+	  <?rfc subcompact="yes"?>
+	  <t hangText="0: Raw TCP:">TLS is not used.</t>
+	  <t hangText="1: TLS TOFU:">TLS using a self-signed server
+	  certificate.</t>
+	  <t hangText="2: TLS CA-NoIP:">TLS using a CA-Based server
+	  certificate, with no IP address extension.</t>
+	  <t hangText="3: TLS CA WithIP:">TLS using a CA-Based server
+	  certificate, with the server's IP address in the subject
+	  alternative name extension (see <xref target="RFC5280"/>
+	  Section 4.2.1.6).</t>
+	  <t hangText="4-255:">Reserved.</t>
+	  <?rfc subcompact="no"?>
+	</list></t>
+
+      <t>If server certificates are to be used, they may be locally
+      generated and then signed by a CA or generated by the CA and
+      loaded.  See <xref target="RFC8635"/>.</t>
+      
+      </section>
+
+    <section anchor="flags" title="Flags">
+
+      <t>Though the Working Group scope for this protocol is within a
+      data center, an issue was raised that, on an internet echange with
+      route server(s), it would attempt to form adjacencies with all
+      members of the exchange.  Hence a Flag field is provided to
+      indicate that a device does not intend to field a TLS/TCP server
+      on the announcing interface, but does seek one or more from
+      peers.</t>
+      
+      <t>Currently, only one Flags field is defined
+	<list style="hanging">
+	  <?rfc subcompact="yes"?>
+	  <t hangText="Bit 0: Client Only">This interface does not
+	  provide a TLS/TCP server.</t>
+	  <t hangText="Bits 1-7:">Reserved.</t>
+	  <?rfc subcompact="no"?>
+	</list></t>
+
+      </section>
+
+    <section anchor="port" title="Port">
+	
+      <t>The Port is the two octet TCP Port Number (default is TBD3) on
+      which the HELLO sender SHOULD have a waiting TLS/TCP (as specified
+      in Flags) server listening unless the Client Only Flag is set.
+      Though the IANA assigned well-known port SHOULD be used, this
+      field allows configuration of alternate ports.</t>
+      
+      </section>
     </section>
 
   <section anchor="tcp" title="TCP Set-Up">
 
-    <t>If the receiver of a HELLO does not agree with the sender's
-    choice of TLS/TCP or does not agree with the verification choice,
-    Self-Signed or CA-based, the receiver SHOULD respond with a HELLO
-    specifying its preferences.</t>
-
     <t>As it is assumed that the configured deployment of a data center
     would have compatible parameters on all devices, any disagreement
     over TLS/TCP or trust anchors MUST be logged; with rate limiting of
@@ -1284,13 +1335,7 @@ Flags (bit):
 
   <section anchor="acks" title="Acknowledgments">
 
-    <t>Many kind people helped with the Layer-2 cousin of this protocol,
+    <t>The authors thank Ben Maddison and Jeff Haas.</t>
-    L3DL.  Cristel Pelsser provided multiple reviews, Harsha Kovuru
-    commented during implementation, Jeff Haas reviewed and commented,
-    Joerg Ott did an early but deep transport review, Joe Clarke
-    provided a useful ops review, John Scudder a deeply serious review
-    and comments, Martijn Schmidt contributed, and Neeraj Malhotra
-    reviewed.</t>
     
     </section>
 
@@ -1304,9 +1349,10 @@ Flags (bit):
     <?rfc include="reference.RFC.4271.xml"?>
     <?rfc include="reference.RFC.5082.xml"?>
     <?rfc include="reference.RFC.5226.xml"?>
-<!--<?rfc include="reference.RFC.5880.xml"?> -->
+    <?rfc include="reference.RFC.5280.xml"?>
 <!--<?rfc include="reference.RFC.6286.xml"?> -->
     <?rfc include="reference.RFC.8174.xml"?>
+    <?rfc include="reference.RFC.8635.xml"?>
     <?rfc include="reference.I-D.ietf-lsvr-l3dl.xml"?>
 <!--<?rfc include="reference.I-D.ietf-lsvr-l3dl-signing.xml"?> -->
     <reference anchor="IANA-PEN" target="https://www.iana.org/assignments/enterprise-numbers/enterprise-numbers">