introduce Fragment-MTU TLV

draft-dekok-emu-teapv2.md

@@ -27,7 +27,7 @@ normative:
   RFC3748:
   RFC8174:
   RFC8446:
-  I-D.ietf-emu-rfc7170bis:
+  RFC9930:
 
 informative:
   RFC6677:
@@ -42,7 +42,7 @@ venue:
 This document defines the Tunnel Extensible Authentication Protocol
 (TEAP) version 2.  It addresses a number of security and
 interoperability issues which were found during the publication of
-TEAPv1 ({{I-D.ietf-emu-rfc7170bis}}).
+TEAPv1 ({{RFC9930}}).
 
 --- middle
 
@@ -52,18 +52,18 @@ Tunnel Extensible Authentication Protocol (TEAP) version 1 was first
 defined in {{?RFC7170}}.  However, implementations of that
 specification were found to have limited interoperability, due to the
 complexity of the design, and to under-specification of the
-cryptographic key deriviations that it defined.
+cryptographic key derivations that it defined.
 
-TEAPv1 was updated and clarified in {{I-D.ietf-emu-rfc7170bis}}.  That
+TEAPv1 was updated and clarified in {{RFC9930}}.  That
 document described a large amount of potential functionality in the
-protocol, but also noted in {{I-D.ietf-emu-rfc7170bis, Section 5.1}}
+protocol, but also noted in {{RFC9930, Section 5.1}}
 that only a small subset of that functionality was interoperable.  In
 addition, the interoperable parts of the protocol had security issues
 which could potentially allow on-path attackers control control over
 the data being transported inside of the TLS tunnel.
 
 We do not review the full security issues with TEAPv1 here.  Instead,
-we define TEAPv2, with new and simpler cryptographic key deriviations.
+we define TEAPv2, with new and simpler cryptographic key derivations.
 These derivations address all of the known issues with TEAPv1.
 
 NOTE: For simplicity, this current draft defines TEAPv2 as a delta
@@ -76,11 +76,11 @@ TEAPv1 document.
 
 Most parts of TEAPv1 are unchanged.  The message and TLV formats are
 the same, as are the derivations for the session_key_seed
-({{I-D.ietf-emu-rfc7170bis, Section 6.1}}).  The derivations for the
+({{RFC9930, Section 6.1}}).  The derivations for the
 Master Session Key (MSK) and the Extended Master Session Key (EMSK)
-({{I-D.ietf-emu-rfc7170bis, Section 6.4}}) have had only minor changes.
+({{RFC9930, Section 6.4}}) have had only minor changes.
 
-The Crypto-Binding TLV {{I-D.ietf-emu-rfc7170bis, Section 4.2.13}} has
+The Crypto-Binding TLV {{RFC9930, Section 4.2.13}} has
 the same format as for TEAPv1, although its value is now calculated
 via a different derivation.  The Crypto-Binding TLV is now used only
 when the inner exchange is an EAP authentication method.
@@ -95,7 +95,7 @@ calculation had significant differences between independent
 implementations.  These differences were due to complex derivations of
 multiple intermediate keys, some of which were defined ambiguously.
 This complexity and lack of clarity lead to interoperability problems.
-TEAPv2 simplifies the key deriviations, reduces the number of
+TEAPv2 simplifies the key derivations, reduces the number of
 intermediate keys, and gives smaller (and hopefully clearer)
 definitions for the derivations.
 
@@ -105,11 +105,11 @@ operations.
 ## Outline of this Document
 
 This document largely follows the same outline as
-{{I-D.ietf-emu-rfc7170bis}}.  Where changes from that document are
+{{RFC9930}}.  Where changes from that document are
 made, the same section titles are used in order to ensure easy
 comparison of the documents.  New sections are added, with new titles.
 For parts of TEAP which are not mentioned herein, this document makes
-no changes from {{I-D.ietf-emu-rfc7170bis}}.
+no changes from {{RFC9930}}.
 
 ## Specification Requirements
 
@@ -129,27 +129,27 @@ Round
 >
 > A round can include multiple inner message exchanges, e.g. EAP-TLS.
 >
-> This term was used in {{I-D.ietf-emu-rfc7170bis}}, but was not
+> This term was used in {{RFC9930}}, but was not
 > defined in that document.
 
 # Negotiation
 
 TEAPv2 uses the same version negotiation method as is defined in
-{{I-D.ietf-emu-rfc7170bis, Section 3.1}}, with the Version field set
+{{RFC9930, Section 3.1}}, with the Version field set
 to two (2) for TEAPv2.
 
 TEAPv2 MUST use TLS 1.3 or later.  TEAPv2 MUST NOT use TLS-PSK.
 
 # Cryptographic Calculations
 
 The crytographic calculations for TEAPv2 have been substantially
-simplified from those defined in {{I-D.ietf-emu-rfc7170bis, Section
+simplified from those defined in {{RFC9930, Section
 6}}.
 
 ## TEAP Authentication Phase 1: Key Derivations {#key-derivations}
 
 The session key seed is the same as defined in
-{{I-D.ietf-emu-rfc7170bis, Section 6.2.1}} for TEAPv2.  That
+{{RFC9930, Section 6.2.1}} for TEAPv2.  That
 definition is reproduced here verbatim:
 
 ~~~~
@@ -166,12 +166,12 @@ inner methods will provide an MSK or an EMSK.
 TEAPv2 uses the Crypto-Binding TLV to protect both parties from the
 attacks outlined in {{RFC6677}}.  As those attacks are only possible
 when the inner method is EAP, TEAPv2 defines key derivations only when
-then inner method is EAP.  TEAPv2 does not define key deriviations or
+then inner method is EAP.  TEAPv2 does not define key derivations or
 use the Crypto-Binding TLV for other inner method exchanges.
 
-The key deriviations described below MUST be done when the inner
+The key derivations described below MUST be done when the inner
 method is EAP (i.e. when the parties exchange EAP-Payload TLVs).  The
-key deriviations described below MUST NOT be done when the inner
+key derivations described below MUST NOT be done when the inner
 method is anything other than EAP (i.e. when the inner method does not
 include EAP-Payload TLVs).
 
@@ -215,7 +215,7 @@ generated from the final round seed ([](#master-key)).
 
 ### Intermediate Key Seeding {#key-seeding}
 
-The intermediate compound key deriviations for TEAPv2 depend on the
+The intermediate compound key derivations for TEAPv2 depend on the
 following RoundSeed structure.  The RoundSeed structure is defined
 using the same syntax as is used for TLS {{RFC8446}}:
 
@@ -337,7 +337,7 @@ method as for TEAPv1.  That definition is reproduced here verbatim:
 
 CMK is taken from the DerivedKey structure which was calculated for
 this round.  The definition of BUFFER is the same as in
-{{I-D.ietf-emu-rfc7170bis, Section 6.3}} for TEAPv1.
+{{RFC9930, Section 6.3}} for TEAPv1.
 
 For TEAPv2, only one CMK is derived for each inner message.  This
 limitation also means that only one Compound-MAC is derived for the
@@ -363,7 +363,7 @@ derivation than was done for TEAPv1.
 The following sections describe the message formats used in TEAPv2.
 The fields are transmitted from left to right in network byte order.
 
-## EAP MTU
+## EAP MTU {#eap-mtu}
 
 {{RFC3748, Section 3.1}} defines a minimum EAP MTU of 1020 octets.
 However, it defines no maximum MTU, {{RFC3748}} also provides no way
@@ -380,7 +380,7 @@ Section 3}} defines a maximum RADIUS packet length of 4096 octets.
 This limit can therefore be in conflict with different local network
 limits seen by the EAP peer.
 
-As a result, TEAPv2 mandates a maximum MTU.  TEAPv2 impementations are
+As a result, TEAPv2 mandates a maximum MTU.  TEAPv2 implementations are
 limited to sending EAP packets which are no larger than 1280 octets in
 size.  That is, the EAP packet Length field ({{RFC3748, Section 4}})
 MUST contain a value which is no larger than 1280.
@@ -392,19 +392,19 @@ message exchanges.
 ## TEAPv2 Message Format
 
 The TEAPv2 message format is identical to that of TEAPv1
-({{I-D.ietf-emu-rfc7170bis, Section 4.1}}) with only one change: the
+({{RFC9930, Section 4.1}}) with only one change: the
 Ver field is set to "2", to indicate that this is TEAPv2.
 
 ## TEAPv2 TLVs
 
 The TEAPv2 TLV format and TLV definitions are identical to that for
-TEAPv1 ({{I-D.ietf-emu-rfc7170bis, Section 4.2}}), with only the
+TEAPv1 ({{RFC9930, Section 4.2}}), with only the
 changes and additions noted below.
 
 ### Crypto-Binding TLV {#crypto-binding}
 
 The format of the TEAPv2 Crypto-Binding TLV is the same as for TEAPv1
-({{I-D.ietf-emu-rfc7170bis, Section 4.2.13}}), with the following
+({{RFC9930, Section 4.2.13}}), with the following
 changes:
 
 * The Version field MUST set to two (2).
@@ -422,6 +422,86 @@ changes:
 * The MSK Compound-MAC field is calculated as described above in
   [](#computing-compound-mac).
 
+### Fragment-MTU TLV {#fragment-mtu-tlv}
+
+The Fragment-MTU TLV allows an EAP peer to indicate its preference of
+MTU to use for the EAP fragments it will receive.
+
+The value MUST reflect any overhead in the transport used by EAP,
+such as EAPOL and RADIUS/EAP-Message, and as such MUST be lower
+than the local link MTU of the peer.
+
+Values lower than 200 bytes are ignored and treated as if 200 was provided.
+
+Values above 1280 are ignored as per the guidance in []{#eap-mtu} and treated
+as if 1280 was provided.
+
+For example, RADIUS sent over a 1500 MTU link has an overhead of at least
+twenty (20) bytes for the RADIUS header, eight (8) bytes for the UDP header,
+ and twenty (20) for either IPv4 or forty (40) bytes for IPv6. For this the
+value of Fragment-MTU MUST be no larger than 1432 and is RECOMMENDED to be
+at least one hundred (100) bytes smaller to cater for additional RADIUS
+attributes and any tunneling transports. The leaves a value of 1332 which
+is higher than 1280 which is the maximum MTU which would make the
+Fragment-MTU TLV superfluous and SHOULD not be sent.
+
+For RADIUS transports, there are two use cases:
+
+ * Home servers can determine if the RADIUS packet was received fragmented
+   and respond with a smaller Fragment-MTU TLV for the originating peer to
+   use.
+
+ * Proxy servers forwarding EAP responses can determine if the RADIUS packet
+   was received fragmented and update the RADIUS request to reflect a
+   reduced value of Framed-MTU as described by {{RFC2869, Section 2.3.3}}.
+
+The value of Fragment-MTU MUST be the smallest of the value received by the
+peer and any locally determined value either decided by the administrator or
+learned from an out-of-bound source such as the RADIUS/Framed-MTU attribute.
+Chosen the smallest value guards against differing link layer MTU that may
+occur due to asymmetric routing of the encapsulating transport such as
+RADIUS.
+
+Upon a peer receiving a Fragment-MTU TLV, it MUST send EAP fragments no
+larger than the value proposed.
+
+The Fragment-MTU TLV MAY appear as an Outer TLV to assist administrators.
+
+The Fragment-MTU TLV 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
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|M|R|         TLV Type          |            Length             |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+|           Fragment MTU        |
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+~~~~
+
+M
+
+> Mandatory, set to zero (0)
+
+R
+
+> Reserved, set to zero (0)
+
+TLV Type
+
+> 20 - Fragment-MTU
+
+Length
+
+> 2
+
+Fragment MTU
+
+> The MTU field is two octets and reflects the preference of the peer
+> for the maximum fragment size to use.
+>
+> Values above 1280 are ignored.
+
 # Security Considerations
 
 # IANA Considerations