diff --git a/draft-ietf-lsvr-l3dl.xml b/draft-ietf-lsvr-l3dl.xml index b2c4ce7..331314d 100644 --- a/draft-ietf-lsvr-l3dl.xml +++ b/draft-ietf-lsvr-l3dl.xml @@ -11,7 +11,7 @@ - + @@ -38,6 +38,20 @@ + + Vigil Security, LLC +
+ + 516 Dranesville Road + Herndon + VA + 20170 + USA + + housley@vigilsec.com +
+ + Arrcus
@@ -114,17 +128,22 @@ API, to BGP-SPF which computes the topology and builds routing and forwarding tables, Enable Layer-3 link liveness such as BFD, - Provide Layer-2 keep-alive messages for session continuity, and - finally - Provide for authenticity verification of protocol messages. + Provide Layer-2 keep-alive messages for session continuity, + Provide for authenticity verification of protocol messages, and + finally. + Communicate the parameters needed to exchange inter-device + Upper Layer Protocol Configuration for upper-layer protocols such + as BGP. + In this document, the use case for L3DL is for point to point links in a datacenter Clos in order to exchange the data needed for BGP-SPF bootstrap and continuity. Once layer-2 connectivity has been leveraged to get - layer-3 addressability and forwarding capabilities, normal layer-3 - forwarding and routing can take over. + layer-3 addressability and forwarding capabilities, parameters for + routing protocols such as BGP can be communicated, and normal + layer-3 forwarding and routing can take over. L3DL might be found to be more widely applicable to a range of routing and similar protocols which need layer-3 discovery and @@ -206,6 +225,10 @@ needed to run safely on a WAN need to be considered, and the appropriate level of security options chosen. + Familiarity with the BGP4 Protocol is + assumed. Familiarity with BGP-SPF, , might be useful. + L3DL assumes a new IEEE assigned EtherType (TBD). The number of addresses of one Encapsulation type on an interface @@ -430,6 +453,13 @@ Transmission Sequence Number informs the receiver that it is the same PDU. + The L3DL OPEN PDU contains an algorithm identifier, a key, and a + L3DL certificate, which can be used to verify signatures on + subsequent PDUs. This document describes two methods of key + generation and signing for use by L3DL, Trust On First Use (TOFU) + and a PKI-based mechanism to provide authentication as well as + session integrity. See . + @@ -1339,6 +1369,290 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) +
+ + To communicate parameters required to configure peering and + operation of Upper-Layer Protocols at IP layer-3 and above, e.g., + BGP sessions on a link, a neutral sub-TLV based Upper-Layer Protocol + PDU is defined as follows: + + + +
+ + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Type = 9 | Payload Length ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ | ULPC Type | AttrCount | ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ Attribute List ... | Sig Type | Signature Len ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ | Signature ... | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + The Type and Payload Length are defined in . + + + ULPC Type: A one octet integer denoting the type of the + upper-layer protocol + + Reserved + BGP + Reserved + + + The one octet AttrCount is the number of attribute sub-TLVs in + the Attribute List. + + The Attribute List is a, possibly null, set of sub-TLVs + describing the configuration attributes of the specific upper-layer + protocol. + + An Attribute consists of a one octet Attribute Type, a one octet + Attribute Length of the number of octets in the Attribute, and a + Payload of arbitrary length up to 253 octets. + + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 1 | Attr Len | Payload | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + +
+ + The parameters needed for BGP peering on a link are exchanged + in sub-TLVs within an Upper-Layer Protocol PDU. The following + describe the various sub-TLVs for BGP. + + The goal is to provide the minimal set of configuration + parameters needed by BGP OPEN to successfully start a BGP peering. + The goal is specifically not to replace or conflict with data + exchanged during BGP OPEN. Multiple sources of truth are a recipe + for complexity and hence pain. + + If there are multiple BGP sessions on a link, e.g., IPv4 and + IPv6, then separate BGP ULPC PDUs should be sent, one for each + address family. + + A peer receiving BGP ULPC PDUs has only one active BGP ULPC PDU + for an particular address family on a specific link at any point + in time; receipt of a new BGP ULPC PDU for a particular address + family replaces the data any previous one; but does not actually + affect the session. + + If there are one or more open BGP sessions, receipt of a new BGP ULPC PDU SHOULD not + affect these sessions. The received data are stored for a future + session restart. + + As a link may have multiple encapsulations and multiple + addresses for an IP encapsulation, which address of which + encapsulation is to be used for the BGP session MUST be + specified. + + For each BGP peering on a link here MUST be one agreed + encapsulation, and the addresses used MUST be in the corresponding + L3DP IPv4/IPv6 Announcement PDUs. If the choice is ambiguous, an + Attribute may be used to signal preferences. + + If a peering address has been announced as a loopback, + i.e. MUST BE flagged as such in the L3DL Encapsulation PDU (see + ), a two or three hop + BGP session will be established. Otherwise a direct one hop + session is used. The BGP session to a loopback will forward to + the peer's address which was marked as Primary in the L3DL + Encapsulation Flags, iff it is in a subnet which is shared with + both BGP speakers. If the primary is not in a common subnet, then + the BGP speaker MAY pick a forwarding next hop that is in a subnet + they share. If there are multiple choices, the BGP speaker SHOULD + have signaled which subnet to choose in an Upper-Layer Protocol + Configuration PDU Attribute. + + Attributes MUST be unique in the Attribute List. I.e. a + particular Attr Type MUST NOT occur more than once in the + Attribute List. If a ULPC PDU is received with more than one + occurrence of a particular Attr Type, an Error ACK MUST be + returned. + + As there are separate PDU Attr Types for IPv4 and IPv6 peering + addresses, separate sessions for the two AFIs MAY be created for + the same ASN in one ULPC PDU. + + + +
+ + The four octet Autonomous System number MUST be specified. + If the AS Number is less than 32 bits, it is padded with high + order zeros. + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 1 | Attr Len = 6 | My ASN ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + + + The four octet BGP IPv4 Address sub-TLV announces the + sender's IPv4 BGP peering source address to be used by the + receiver. At least one of IPv4 or IPv6 BGP source addresses + MUST be announced. + + As usual, the BGP OPEN capability negotiation will determine + the AFI/SAFIs to be transported over the peering, see . + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 2 | Attr Len = 5 | My IPv4 Peering Address ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +~ | Prefix Len | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP IPv6 Address sub-TLV announces the sender's 16 octet + IPv6 BGP peering source address and one octet Prefix Length to + be used by the receiver. At least one of IPv4 or IPv6 BGP + source addresses MUST be announced. + + As usual, the BGP OPEN capability negotiation will determine + the AFI/SAFIs to be transported over the peering, see . + + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 3 | Attr Len = 17 | | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +| | ++ + +| My IPv6 Peering Address | ++ + +| | ++ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | Prefix Len | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP Authentication sub-TLV provides any authentication + data needed to OPEN the BGP session. Depending on operator + configuration of the environment, it might be a simple MD5 key + (see ), the name of a key chain in a + KARP database (see ), or one of multiple + Authentication sub-TLVs to support hop. + + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 4 | Attr Len | ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ +~ BGP Authentication Data ... ~ ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ +
+ +
+ + The BGP session OPEN has extensive, and a bit complex, + capability negotiation facilities. In case one or more extra + attributes might be needed, the two octet BGP Miscellaneous + Flags sub-TLV may be used. No flags are currently defined. + + +
+ + 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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Attr Type = 5 | Attr Len = 4 | Misc Flags | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + Misc Flags: + + + GTSM + BFD + Must be zero + + + The GTSM flag, when 1, indicates that the sender wishes to + enable the Generalized TTL Security + Mechanism for the session. + + The BFD flag, when 1, indicates that the sender wishes to + enable the Bidirectional Forwarding + Detection for the session. + +
+ +
+ +
+
+ +
+ +
+ + + The process for verifying non-OPEN PDUs is slightly simpler, + but follows the same basic pattern as for OPEN PDUs. + + + + + + + Verify that the PDU is syntactically correct, and extract + the Sig Type and Signature fields. + + + + Verify that Sig Type refers to the same algorithm suite as + the Auth Type recorded during verification of the OPEN PDU. + + + + Construct the "message to be verified" by truncating the PDU + to remove the Signature field. + + + + Verify the message constructed above against the recorded + session key using the rules for the specific signature + suite. + + + + + + + If any of the above verification steps fail, generate an error + using error code 3 ("Signature failure in PDU"). + + + + +
+ + + +
+ + + Using a PKI is almost the same as using TOFU, but with one + additional step: during verification of an OPEN PDU, after + extracting the Key field from the PDU but before attempting to use + it to verify the OPEN PDU signature, the receiver MUST verify the + received key against the PKI to confirm that it's an authorized + key. + + + + Generating an OPEN PDU using the PKI method requires a + certificate, which must be supplied via out of band + configuration. The certificate is a signature of the public key + to be sent in the Key field of the OPEN PDU, signed by the trust + anchor private key. + + + + Verifying an OPEN PDU using the PKI method requires the public + key of the trust anchor, which the receiver uses to verify the + certificate, thereby demonstrating that the supplied public key + represents an authorized L3DL speaker in this administrative + domain. + + + + We use the term "certificate" here in the generic sense, not as + defined in . X.509 certificates are not + used here; X.509 certificates are more complicated than needed + for L3DL. The L3DL certificates are just signatures of one key + (the public key supplied in the Key field of the OPEN PDU) that + can be verified by another trusted public key (the trust anchor). + + +
+ + + Generating and signing the OPEN PDU with the PKI method is + almost the same as in . The + only difference is that the PKI method MUST supply the + appropriate certificate in the Certificate field. + + + + Note that the Auth Type field applies to both the Key and + Certificate fields. That is: the certificate uses the same + certificate suite as the session keys, L3DL does not support + cross-algorithm-suite certification. + + +
+ +
+ + + Verifying the OPEN PDU with PKI is similar to verifying with + TOFU as described in , but + includes one critical extra step: + + + + After extracting the Key field from the PDU but before + verifying the Signature, extract the Certificate field and + verfiy that the Certificate is a valid signature of the Key + field, according to the rules for the signature suite + specified by Auth Type. If this step fails, handle as in + . + + +
+ +
+ +
+ + + Whether to use TOFU, PKI, or no signatures at all is a matter of + local policy, to be decided by the operator. The useful + policy combinations for Key and Certificate are probably: + + + + + + + Not signing: sender need not sign, receiver does not check. + + + + Require TOFU: sender MUST supply key and receiver MUST + check, but L3DL certificates not needed and ignored if sent. + + + + Allow TOFU: sender MUST supply key and receiver MUST check, + receiver SHOULD check certificate if supplyed by sender. + + + + Require PKI: sender MUST supply key and L3DL certificate, + receiver MUST check signature and verify the L3DL certificate. + + + + + +
+ +
+ + Modern key management allows for agility in 'rolling' to a new + key or even algorithm in case of key expiry, key compromise, or + merely prudence. Declaring a new key with an L3DL OPEN PDU would + cause serious churn in topology as a new OPEN PDU may cause a + withdraw of previously announced encapsulations. Therefore, a + gentler rekeying is needed. + + Prior to 'rolling' to a new key or new algorithm, a new public/private + key pair is generated. If PKI is being used, then the trust anchor + also signs the new public key to create a new L3DL certificate. + + + +
+ + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type = 8 | Payload Length | New Key Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Key Length | New Key ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | New Cert Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | New Certificate ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Old Key Type | Old Signature Length | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | Old Signature ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +
+ + The New Key Type, New Key Length, New Key, New Cert Length, and + New Certificate fields declare the replacement algorithm, key, and + L3DL certificate. + + The NEWKEY PDU is signed using the current (soon to be old) + algorithm and key. + + The sender and the receiver should be cautious of signature + algorithm downgrade attacks. + + To avoid possible race conditions, the receiver SHOULD accept + signatures using either the new or old key for a configurable time + (default 30 seconds). This is intended to accommodate situations + such as senders with high peer out-degree and a single per-device + asymmetric key. + + If the sender does not receive an ACK in the normal window, + including retransmission, then the sender MAY choose to allow a + session reset by either issuing a new OPEN PDU or by letting the + receiver eventually have a signature failure (error code 3) on a + PDU. + + + The rekeying operation changes the session key and the associated + algorithm described in . The + NEWKEY PDU itself is verified using the old algorithm and session + key. After the NEWKEY PDU has been accepted, subsequent PDUs are + verified with the new algorithm and the new session key. + + +
+ + +
An implementation SHOULD provide the ability to configure each @@ -1604,6 +2310,39 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) target="tlv"/>) to save computation, then a MITM could fake a session being alive. + As the ULPC PDU may contain keying material, see , it SHOULD BE signed. + + Any keying material in the PDU SHOULD BE salted and hashed. + + The BGP Authentication sub-TLV provides for provisioning MD5, + which is a quite weak hash, horribly out of fashion, and kills + puppies. But, like it or not, it has been sufficient against the + kinds of attacks BGP TCP sessions have endured. So it is what BGP + deployments use. + + The TOFU method requires a leap of faith to accept the key in the + OPEN PDU, as it can not be verified against any authority. Hence it + is jokingly referred to as Married On First Date. The assurance it + does provide is that subsequent signed PDUs are from the same peer. + And data integrity is a positive side effect of the signature + covering the payload. + + The PKI method offers assurance that the L3DL certificate, and + hence the public key, provided in the OPEN PDU are authorized + by a central authority, e.g. the network's security team. The + onward assurance of talking to the same peer and data integrity are + the same as in the TOFU method. + + With the PKI method, automated device provisioning could + restrict which L3DL certificates are allowed from which peers + on a per interface basis. This would complicate key rolls. Where + one draws the line between rigidity, flexibility, and security + varies. + + The REKEY PDU is open to abuse to create a signature algorithm + downgrade attack. +
@@ -1628,13 +2367,34 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) 5 IPv6 Announcement 6 MPLS IPv4 Announcement 7 MPLS IPv6 Announcement - 8-254 Reserved + 8 NEWKEY + 9 ULPC + 10-254 Reserved 255 VENDOR
+
+ + This document requests the IANA create a registry for L3DL ULPC + Type, which may range from 0 to 255. The name of the registry + should be L3DL-ULPC-Type. The policy for adding to the registry is + RFC Required per , either standards track or + experimental. The initial entries should be the following: +
+ + Value Name + ----- ------------------- + 0 Reserved + 1 BGP + 2-255 Reserved + +
+ +
+
This document requests the IANA create a registry for L3DL @@ -1648,7 +2408,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) Number Name ------ ------------------- 0 Null - 1-255 Reserved + 1 TOFU - Trust On First Use + 2 PKI + 3-255 Reserved @@ -1732,7 +2494,9 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) + + @@ -1741,6 +2505,13 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) + + + DNS Security Algorithm Numbers + + + + IANA Private Enterprise Numbers @@ -1778,6 +2549,10 @@ uint32_t sbox_checksum_32(const uint8_t *b, const size_t n) + + + +