< draft-eastlake-trill-group-keying-00.txt   draft-eastlake-trill-group-keying-01.txt >
INTERNET-DRAFT Donald Eastlake INTERNET-DRAFT Donald Eastlake
Intended status: Proposed Standard Huawei Intended status: Proposed Standard Huawei
Expires: January 7, 2017 July 8, 2016 Expires: June 29, 2017 December 28, 2016
TRILL: Group Keying TRILL: Group Keying
<draft-eastlake-trill-group-keying-00.txt> <draft-eastlake-trill-group-keying-01.txt>
Abstract Abstract
This document specifies a general group keying protocol and provides This document specifies a general group keying protocol. It also
a use profile for its application to TRILL Extended RBridge Channel provides use profiles for the application of this group keying
message security. protocol to multi-destination TRILL Extended RBridge Channel message
security and TRILL over IP packet security.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Distribution of this document is unlimited. Comments should be sent Distribution of this document is unlimited. Comments should be sent
to the authors or the TRILL working group mailing list: to the authors or the TRILL working group mailing list:
trill@ietf.org. trill@ietf.org.
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction............................................3 1. Introduction............................................3
1.1 Terminology and Acronyms..............................3 1.1 Terminology and Acronyms..............................3
2. Group Keying Protocol...................................5 2. Group Keying Protocol...................................5
2.1 Assumptions............................................5 2.1 Assumptions............................................5
2.2 Group Keying Procedure Overview........................5 2.2 Group Keying Procedure Overview........................5
2.3 Transmission and Receipt of Group Data Messages........6 2.3 Transmission and Receipt of Group Data Messages........6
2.4 Changes in Group Membership or GKd.....................6 2.4 Changes in Group Membership or GKd.....................6
2.5 Group Keying Messages..................................7 2.5 Group Keying Messages..................................7
2.6 Set Key Message........................................9 2.6 Set Key Message........................................9
2.7 Use, Delete, or Disuse Key Messages...................11 2.7 Use, Delete, Disuse, or Deleted Key Messages..........11
2.8 Response Message......................................12 2.8 Response Message......................................12
2.8.1 Response Codes......................................14 2.8.1 Response Codes......................................14
2.8 No-Op Message.........................................15 2.8 No-Op Message.........................................15
2.9 General Security Considerations.......................16 2.9 General Security Considerations.......................16
3. Extended RBridge Channel Group Keyed Security..........17 3. Extended RBridge Channel Group Keyed Security..........17
3.1 Transmission of Group Keying Messages.................17 3.1 Transmission of Group Keying Messages.................17
3.2 Transmission of Protected Multi-destination Data......18 3.2 Transmission of Protected Multi-destination Data......18
4. IANA Considerations....................................19 4. TRILL Over IP Group Keyed Security.....................19
4.1 Group Keying Protocol.................................19 4.1 Transmission of Group Keying Messages.................19
4.2 Group Keying RBridge Channel Protocol Numbers.........20 4.2 Transmission of Protected Multi-destination Data......19
4.3 Group Secured Extended RBridge Channel SType..........20
5. Security Considerations................................21 5. IANA Considerations....................................20
5.1 Group Keying Protocol.................................20
5.2 Group Keying RBridge Channel Protocol Numbers.........21
5.3 Group Secured Extended RBridge Channel SType..........21
Normative References......................................22 6. Security Considerations................................22
Informative References....................................23
Acknowledgements..........................................24 Normative References......................................23
Authors' Addresses........................................25 Informative References....................................24
Acknowledgements..........................................25
Authors' Addresses........................................26
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
1. Introduction 1. Introduction
This document specifies a general group keying protocol in Section 2. This document specifies a general group keying protocol in Section 2.
In addition, it provides, in Section 3, the use profile for the In addition, it provides, in Section 3, the use profile for the
application of this group keying protocol to TRILL [RFC6325] application of this group keying protocol to TRILL [RFC6325]
[RFC7780] Extended RBridge Channel message security [RFC7178] [RFC7780] Extended RBridge Channel message security [RFC7178]
[ExtendedChannel]. It is anticipated that there will be other uses [RFC7978]. It is anticipated that there will be other uses for this
for this group keying protocol, for example in connection with link group keying protocol, for example in connection with link security
security in [TRILLoverIP]. in [TRILLoverIP].
1.1 Terminology and Acronyms 1.1 Terminology and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses terminology and acronyms defined in [RFC6325] and This document uses terminology and acronyms defined in [RFC6325] and
[RFC7178]. Some of these are repeated below for convenience along [RFC7178]. Some of these are repeated below for convenience along
with additional new terms and acronyms. with additional new terms and acronyms.
AES - Advanced Encryption Standard. AES - Advanced Encryption Standard.
Data Label - VLAN or FGL. Data Label - VLAN or FGL.
DTLS - Datagram Transport Level Security [RFC6347]. DTLS - Datagram Transport Level Security [RFC6347].
GKd - A distinguished station in a group whose distributed group FGL - Fine Grained Label [RFC7172].
keying (Section 2) is in use.
GKd - A distinguished station in a group that is in charge of
which group keying (Section 2) is in use.
GKs - Stations in a group other than GKd (Section 2). GKs - Stations in a group other than GKd (Section 2).
HKDF - Hash based Key Derivation Function [RFC5869]. HKDF - Hash based Key Derivation Function [RFC5869].
IS-IS - Intermediate System to Intermediate Systems [RFC7176]. IS-IS - Intermediate System to Intermediate System [RFC7176].
keying material - The set of a Key ID, a secret key, and a cypher keying material - The set of a Key ID, a secret key, and a cypher
suite. suite.
PDU - Protocol Data Unit. PDU - Protocol Data Unit.
RBridge - An alternative term for a TRILL switch. RBridge - An alternative term for a TRILL switch.
SHA - Secure Hash Algorithm [RFC6234]. SHA - Secure Hash Algorithm [RFC6234].
skipping to change at page 5, line 13 skipping to change at page 5, line 13
[RFC6325] [RFC7780], sometimes referred to as an RBridge. [RFC6325] [RFC7780], sometimes referred to as an RBridge.
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
2. Group Keying Protocol 2. Group Keying Protocol
This section defines a general Group Keying Protocol that provides This section defines a general Group Keying Protocol that provides
shared secret group keys. Any particular use of this protocol will shared secret group keys. Any particular use of this protocol will
require a profiling giving further details and specifics for that require a profiling giving further details and specifics for that
use. The protocol is not suitable for discovery messages but is use. The protocol is not suitable for discovery messages but is
intended for use between members of a group all of which are already intended for use between members of a group that have already
known to each other. established pair-wise security.
2.1 Assumptions 2.1 Assumptions
The following are assumed: The following are assumed:
- All pairs of stations in the group can engage in pairwise - All pairs of stations in the group can engage in pairwise
communication with unicast messages and each can groupcast a communication with unicast messages and each can groupcast a
message to the other group members. message to the other group members.
- At any particular time, there is a distinguished station GKd in - At any particular time, there is a distinguished station GKd in
the group that is in charge of keying for the groupcast data the group that is in charge of keying for the groupcast data
messages to be sent to the group. The group wide shared secret messages to be sent to the group. The group wide shared secret
skipping to change at page 6, line 12 skipping to change at page 6, line 12
dynamic key at each GKs while an older dynamic key is in use so that dynamic key at each GKs while an older dynamic key is in use so that
GKd can more promptly roll over to the new key when appropriate. GKd can more promptly roll over to the new key when appropriate.
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
To avoid an indefinite build up of keying material at a GKs, keys To avoid an indefinite build up of keying material at a GKs, keys
have a lifetime specified by GKd and GKd can send a message deleting have a lifetime specified by GKd and GKd can send a message deleting
a key. (GKd can also send a message indicating that a key is no a key. (GKd can also send a message indicating that a key is no
longer to be used but leaving it set.) Should the space available at longer to be used but leaving it set.) Should the space available at
a GKs for keying material be exhausted, on receipt of a Set Key a GKs for keying material be exhausted, on receipt of a Set Key
keying message for a new key ID GKs discards the least recently used keying message for a new key ID GKs discards a dynamic key it has and
dynamic key it has and originates a Delete Key message to GKd to originates a Delete Key message to the source of that dynamic key.
notify GKd that it has discarded that dynamic key and to which GKd
responds.
2.3 Transmission and Receipt of Group Data Messages 2.3 Transmission and Receipt of Group Data Messages
If a group has only two members, then pairwise security is used If a group has only two members, then pairwise security is used
between them. between them.
When a group has more than two members and a station in the group When a group has more than two members and a station in the group
transmits a data message to the group, if the transmitter has one or transmits a data message to the group, if the transmitter has one or
more keys set by GKd that it has been instructed to use, it uses one more keys set by GKd that it has been instructed to use, it uses one
of those keys and its associated cypher suite to groupcast the data of those keys and its associated cypher suite to groupcast the data
skipping to change at page 6, line 43 skipping to change at page 6, line 41
the group, if the receiver has the key referenced by the data message the group, if the receiver has the key referenced by the data message
the receiver decrypts and verifies it. If verification fails or if the receiver decrypts and verifies it. If verification fails or if
the receiver does not have the required key, the receiver discards the receiver does not have the required key, the receiver discards
the data message. Thus whether GKs has been directed to "use" a key the data message. Thus whether GKs has been directed to "use" a key
by GKd is relevant only to transmission, not reception. by GKd is relevant only to transmission, not reception.
2.4 Changes in Group Membership or GKd 2.4 Changes in Group Membership or GKd
When a new station joins the group, GKd should send that station the When a new station joins the group, GKd should send that station the
currently in-use group key and instruct it to use that key and send currently in-use group key and instruct it to use that key and send
it other keys known to the group members. it other keys known to the group members and intended for future use.
If GKd detects that one or more stations that were members of the If GKd detects that one or more stations that were members of the
group are no longer members of the group, it SHOULD generate and group are no longer members of the group, it SHOULD generate and
distribute a new group key to the remaining group members, instruct distribute a new group key to the remaining group members, instruct
them to use this new key, and delete from them any old keys known to them to use this new key, and delete from them any old keys known to
the departed group member station(s) or at least instructing them to the departed group member station(s) or at least instructing them to
disuse such old keys that are marked for use; however, in the case of disuse such old keys that are marked for use; however, in the case of
groups with large and/or highly dynamic membership, where a station groups with large and/or highly dynamic membership, where a station
might frequently leave and then rejoin, it may, as a practical might frequently leave and then rejoin, it may, as a practical
matter, be necessary to rekey less frequently.
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
matter, be necessary to rekey less frequently.
A new group member can become GKd due to the previous GKd leaving the A new group member can become GKd due to the previous GKd leaving the
group or a configuration change or the like. A GKs MUST NOT use group or a configuration change or the like. A GKs MUST NOT use
keying material set by a station that it determines is not GKd. To keying material set by a station that it determines is not GKd. To
avoid a gap in service, a station that is not GKd MAY set keying avoid a gap in service, a station that is not GKd MAY set keying
material at other stations in the group; however, such a non-GKd material at other stations in the group; however, such a non-GKd
station cannot set the use flag for any such keying material. It is station cannot set the use flag for any such keying material. It is
RECOMENDED that the second highest priority station to be GKd set RECOMENDED that the second highest priority station to be GKd set
such keying material at all other stations in the group. Should a such keying material at all other stations in the group. Should a
station run out of room for keying material, it SHOULD discard keying station run out of room for keying material, it SHOULD discard keying
material set by a station with lower priority to be GKd before material set by a station with lower priority to be GKd before
discarding keying material set by a higher priority station. discarding keying material set by a higher priority station and among
keys set by GKd is SHOULD discard the lest recently used first.
2.5 Group Keying Messages 2.5 Group Keying Messages
Keying messages start with a Version number. This document specifies Keying messages start with a Version number. This document specifies
Version zero. Version zero.
Keying messages are structured as Keying messages are structured as
o a Version number, o a Version number,
o a Response flag, o a Response flag,
o a Key ID length, o a Key ID length,
skipping to change at page 8, line 45 skipping to change at page 8, line 45
KeyID1Lngth, KeyID1 - KeyID1 identifies the stable AES-256 key KeyID1Lngth, KeyID1 - KeyID1 identifies the stable AES-256 key
wrapping key (also known as the Key Encrypting Key (KEK)) wrapping key (also known as the Key Encrypting Key (KEK))
as further specified in the use profile. KeyID1Lngth is a as further specified in the use profile. KeyID1Lngth is a
byte that gives the length of KeyID1 in bytes as an byte that gives the length of KeyID1 in bytes as an
unsigned integer. unsigned integer.
Use Type - Specifies the particular group security use profile Use Type - Specifies the particular group security use profile
such as RBridge Extension (Section 3) or IP link such as RBridge Extension (Section 3) or IP link
[TRILLoverIP]. [TRILLoverIP].
Pad1 Length, Pad1 - Padding to obscure the metadata consisting Pad1 Length, Pad1 - Padding to obscure the non-padded message
of the message size. Pad1 Length may be from 0 to 255 and size. Pad1 Length may be from 0 to 255 and gives the length
gives the length of the padding as an unsigned integer. of the padding as an unsigned integer. Each byte of padding
Each byte of padding MUST be equal to Pad1 Length. For MUST be equal to Pad1 Length. For example, 3 bytes of
example, 3 bytes of padding with length is 0x03030303. padding with length is 0x03030303.
AES Wrap Length - An unsigned byte that gives the length of the AES Wrap Length - An unsigned byte that gives the length of the
AES Wrapped Material in units of 8 bytes. The length of AES AES Wrapped Material in units of 8 bytes. The length of AES
key wrapped material is, as specified in [RFC5649], always key wrapped material is, as specified in [RFC5649], always
a multiple of 8 bytes (64 bits) and not less than 16 bytes. a multiple of 8 bytes (64 bits) and not less than 16 bytes.
Thus an AES Wrap Length of 0 or 1 is invalid. Thus an AES Wrap Length of 0 or 1 is invalid.
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
AES Wrapped Material - The output of the AES Key Wrapping AES Wrapped Material - The output of the AES Key Wrapping
operation on the message vector of fields using the operation on the message vector of fields using the
specified stable key. specified stable key.
The vector of fields contained within the AES-256 key wrapping is The vector of fields contained within the AES-256 key wrapping is
specified for the various types of keying messages in subsections specified for the various keying messages in subsections below. The
below. The contents of this wrapped vector are protected by the AES contents of this wrapped vector are protected by the AES wrapping as
wrapping as well as being authenticated and super-encrypted by the well as being authenticated and super-encrypted by the pairwise keyed
pairwise keyed security used for sending the overall keying message. security used for sending the overall keying message. The stable key
The stable key used for AES wrapping MUST be different from the outer used for AES wrapping MUST be different from the outer message
message pairwise key. pairwise key.
Each group keying message contains, in the AES wrapped vector of Each group keying message contains, in the AES wrapped vector of
fields, a message type and a message ID set by the sender of a fields, a message type and a message ID set by the sender of a
request that are returned in the corresponding response to assist in request. These fields are returned in the corresponding response to
the matching of response to requests, except that there is no assist in the matching of response to requests, except that there is
response to the No-Op message. no response to the No-Op message.
If no response is received to a request (other than a No-Op message) If no response is received to a request (other than a No-Op message)
for an amount of time configurable in milliseconds from 1 to ( 2**15 for an amount of time configurable in milliseconds from 1 to ( 2**15
- 1 ), the request is re-transmitted with the same message ID. These - 1 ), the request is re-transmitted with the same message ID. These
retries can occur up to a configurable number of times from 1 to 8. retries can occur up to a configurable number of times from 1 to 8.
Unless otherwise provided in the particular use profile, the default Unless otherwise provided in the particular use profile, the default
response delay threshold is 200 milliseconds and the default maximum response delay threshold is 200 milliseconds and the default maximum
number of retries is 3. number of retries is 3.
Keying messages are sent with a priority configurable on a per device Keying messages are sent with a priority configurable on a per device
skipping to change at page 10, line 43 skipping to change at page 10, line 43
The fields are as follows: The fields are as follows:
Msg Type = 1 for Set Key message Msg Type = 1 for Set Key message
Msg ID - A 3 byte quantity to be included in the corresponding Msg ID - A 3 byte quantity to be included in the corresponding
response message to assist in matching requests and response message to assist in matching requests and
responses. Msg ID zero has a special meaning in responses responses. Msg ID zero has a special meaning in responses
and MUST NOT be used in a Set Key message or any other and MUST NOT be used in a Set Key message or any other
group keying request message. group keying request message.
Pad2 Length, Pad2 - Padding to obscure the metadata consisting Pad2 Length, Pad2 - Padding to obscure the size of the unapdded
of size of the AES wrapped data. Pad2 Length may be from 0 AES wrapped data. Pad2 Length may be from 0 to 255 and
to 255 and gives the length of the padding as an unsigned gives the length of the padding as an unsigned integer.
integer. Each byte of padding MUST be equal to Pad1 Length. Each byte of padding MUST be equal to Pad1 Length. For
For example, 2 bytes of padding with length byte is example, 2 bytes of padding with length byte is 0x020202.
0x020202.
Other - Additional information if specified in the use profile. Other - Additional information if specified in the use profile.
If Other information in this message is not mentioned in If Other information in this message is not mentioned in
the use profile, there is none and this portion of the the use profile, there is none and this portion of the
wrapped information is null. If a use profile specifies wrapped information is null. If a use profile specifies
Other information it must be possible to determine its Other information it must be possible to determine its
length so that following fields can be properly parsed and length so that following fields can be properly parsed and
so that the size of the Key field can be deduced. so that the size of the Key field can be deduced.
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
skipping to change at page 11, line 37 skipping to change at page 11, line 37
and the length of the preceding fields. and the length of the preceding fields.
If GKs already has a dynamic key set under KeyID2, the key's value If GKs already has a dynamic key set under KeyID2, the key's value
and associated cypher suite are compared with those in the Set Key and associated cypher suite are compared with those in the Set Key
messages. If they are the same, the only receiver action is to update messages. If they are the same, the only receiver action is to update
the Lifetime information associated with KeyID2 and send a Response the Lifetime information associated with KeyID2 and send a Response
message. If they are different, the lifetime, cypher suite, and key message. If they are different, the lifetime, cypher suite, and key
(and possibly Other material) are replaced, the use flag is cleared, (and possibly Other material) are replaced, the use flag is cleared,
and a Response message sent. and a Response message sent.
2.7 Use, Delete, or Disuse Key Messages 2.7 Use, Delete, Disuse, or Deleted Key Messages
The structure of the wrapped material for the Use Key, Delete Key, The structure of the wrapped material for the Use Key, Delete Key,
and Disuse Key keying messages are the same as each other except for and Disuse Key keying messages are the same as each other except for
the message type. This structure is shown in Figure 2.3 the message type. This structure is shown in Figure 2.3
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Msg Type = t | 1 byte | Msg Type = t | 1 byte
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 12, line 23 skipping to change at page 12, line 23
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
| Padding Pad2 Length bytes | Padding Pad2 Length bytes
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
| Other Variable size | Other Variable size
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
| KeyID2 Length | 1 byte | KeyID2 Length | 1 byte
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| KeyID2 ... KeyID2 bytes | KeyID2 ... KeyID2 bytes
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 2.3. Use, Delete, or Disuse Key Message Inner Structure Figure 2.3. Use, Delete, Disuse, or Deleted Key Message
The Msg Type field specifies the particular message as follows: The Msg Type field specifies the particular message as follows:
Msg Type Message Msg Type Message
-------- ---------- -------- ----------
2 Use Key 2 Use Key
3 Delete Key 3 Delete Key
4 Disuse Key 4 Disuse Key
5 Deleted Key
The remaining fields are as specified in Section 2.4. KeyID2 The remaining fields are as specified in Section 2.4. KeyID2
indicates the key to be used, deleted, or for which use should cease indicates the key to be used, deleted, for which use should cease, or
depending on the message type. which has been deleted, depending on the message type.
It is RECOMMENDED that these messages be padded so as to be the same It is RECOMMENDED that these messages be padded so as to be the same
length as a typical Set Key message. length as a typical Set Key message.
When a GKs spontaneously deletes a key and sends a Delete key message The Deleted Key is sent by a station believing itself to be GKd
to GKd, the Msg ID used is created by GKs from a space of Msg IDs instructing some GKs to delete a key. When a GKs spontaneously
associated with GKs which is independent of the Msg IDs used in deletes a key, it sends a Deleted Key message to the station from
requests originated by GKd. which it received the key. The message types for Delete Key and
Deleted Key are different to minimize confusion in corner cases such
as the GKd changing while messages are in flight. The Msg ID used in
a Deleted Key message is created by the sending GKs from a space of
Msg IDs associated with that GKs which is independent of the Msg IDs
used in requests originated by GKd.
2.8 Response Message 2.8 Response Message
The structure of the wrapped material for the Response group keying The structure of the wrapped material for the Response group keying
message is as show below in Figure 2.4. A response message is message is as show below in Figure 2.4. A response message is
INTERNET-DRAFT TRILL: Group Keying
indicated by the R bit in the first byte of the message outside the indicated by the R bit in the first byte of the message outside the
key wrapping. key wrapping.
INTERNET-DRAFT TRILL: Group Keying A response MUST NOT be sent due to the receipt of a response. The R
bit is outside of the key wrapping so that this rule can be enforced
even in cases of difficulty in unwrapping.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Msg Type = n | 1 byte | Msg Type = n | 1 byte
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg ID 3 bytes | | Msg ID 3 bytes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad2 Length | 1 bytes | Pad2 Length | 1 bytes
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
| Padding Pad2 Length bytes | Padding Pad2 Length bytes
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
skipping to change at page 13, line 27 skipping to change at page 13, line 34
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
| Response Code | 1 byte | Response Code | 1 byte
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| ReqPartLength | 1 byte | ReqPartLength | 1 byte
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
| Request Part ReqPartLenth bytes | Request Part ReqPartLenth bytes
+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-...
Figure 2.4. Response Message Inner Structure Figure 2.4. Response Message Inner Structure
A response MUST NOT be sent due to the receipt of a response.
Except as specified below, the fields are as specified for the Key Except as specified below, the fields are as specified for the Key
Set message. Set message.
Msg Type, Msg ID - The content of these field is copied from Msg Type, Msg ID - The content of these field is copied from
the message in reply to which this Response message is sent the message in reply to which this Response message is sent
unless there is an error that stops the replying station unless there is an error that stops the replying station
from determining them, in which case the special value zero from determining them, in which case the special value zero
is used for the Msg Type and Msg ID. Errors of this type is used for the Msg Type and Msg ID. Errors where the Msg
are indicated by a Response Code with their high order bit Type and ID could not be determined are indicated by a
set to one, that is, the 0b10000000 bit set. Response Code with their high order bit set to one, that
is, the 0b10000000 bit set.
Response Code - An unsigned byte giving the response as Response Code - An unsigned byte giving the response as
enumerated in Table 2.2 in Section 2.8.1. Any Response enumerated in Table 2.2 in Section 2.8.1. Any Response
Code other than a success indicates that the receiver took Code other than a success indicates that the receiver took
no action on the request other than sending an error no action on the request other than sending an error
Response message. Response message.
ReqPartLength, Request Part: It is usually usefully to include ReqPartLength, Request Part: It is usually usefully to include
some or all of the request in error responses. some or all of the request in error responses.
- If the Response Code high order two bits are zero, the - If the Response Code high order two bits are zero, the
request succeeded and ReqPartLength MUST be set to zero request succeeded and ReqPartLength MUST be set to zero
so Request Part will be null. so Request Part will be null.
INTERNET-DRAFT TRILL: Group Keying
- If the Response Code high order two bits are zero one - If the Response Code high order two bits are zero one
(0b01), then there was an error in the part of the (0b01), then there was an error in the part of the
request inside the AES key wrapping but the unwrap request inside the AES key wrapping but the unwrap
process was successful. ReqPartLength is the length of process was successful. ReqPartLength is the length of
the request message material include in the Request Part the request message material include in the Request Part
field. The included request material is from the field. The included request material is from the
unwrapped vector of fields started with the Msg Type unwrapped vector of fields started with the Msg Type
INTERNET-DRAFT TRILL: Group Keying
byte. byte.
- If the Response Code high order two bits is one (the - If the Response Code high order bit is one (the
0b10000000 is set), then there was an error parsing the 0b10000000 is set), then there was an error parsing the
material outside the AES key wrap or an error in the AES material outside the AES key wrap or an error in the AES
unwrapping process. ReqPartLength is the length of the unwrapping process. ReqPartLength is the length of the
request message part included in the Request Part field. request message part included in the Request Part field.
The included part of the request starts with the first The included part of the request starts with the first
byte of the message (the byte containing the version, byte of the message (the byte containing the version,
response flag, and KeyID1 Length). response flag, and KeyID1 Length).
2.8.1 Response Codes 2.8.1 Response Codes
The high order two bits of the Response Code have meaning as shown in The high order two bits of the Response Code have meaning as shown in
Table 2.1. Table 2.1.
Top 2 Bits Category Top 2 Bits Category
---------- ---------- ---------- ----------
0b00 Success 0b00 Success
0b01 AES wrap contents 0b01 AES wrap contents
0b10 Outside of AES wrap contents 0b10/11 Outside of AES wrap contents
0b11 Response to a data message
Response Response Response Response
Decimal Hex Meaning Decimal Hex Meaning
-------- -------- ---------- -------- -------- ----------
0 0x00 Success 0 0x00 Success
1 0x01 Success and the key at an existing key ID was 1 0x01 Success and the key at an existing key ID was
changed changed
2-47 0x02-0x2F Unassigned 2-47 0x02-0x2F Unassigned
48-63 0x30-0x3F Reserved for special success codes defined in 48-63 0x30-0x3F Reserved for special success codes defined in
use profiles use profiles
skipping to change at page 14, line 49 skipping to change at page 15, line 4
65 0x41 Unknown or zero Msg Type in a request 65 0x41 Unknown or zero Msg Type in a request
66 0x42 Zero Msg ID in a request 66 0x42 Zero Msg ID in a request
68 0x43 Invalid length KeyID2 68 0x43 Invalid length KeyID2
69 0x44 Unknown KeyID2 69 0x44 Unknown KeyID2
70 0x45 Invalid length CypherSuite 70 0x45 Invalid length CypherSuite
71 0x46 Unknown CyperSuite 71 0x46 Unknown CyperSuite
72 0x47 Bad Key (see Note 3 below) 72 0x47 Bad Key (see Note 3 below)
73-111 0x49-0x6F Unassigned 73-111 0x49-0x6F Unassigned
112-127 0x70-0x7F Reserved for error codes defined in use 112-127 0x70-0x7F Reserved for error codes defined in use
profiles and related to the AES wrapped profiles and related to the AES wrapped
INTERNET-DRAFT TRILL: Group Keying
contents contents
128 0x80 Malformed message (see Note 1 below) 128 0x80 Malformed message (see Note 1 below)
129 0x81 Invalid length KeyID1 129 0x81 Invalid length KeyID1
130 0x82 Unknown KeyID1 130 0x82 Unknown KeyID1
131 0x83 Unknown Use Type 131 0x83 Unknown Use Type
131 0x84 AES unwrap fails test 1, see Section 3 131 0x84 AES unwrap fails test 1, see Section 3
INTERNET-DRAFT TRILL: Group Keying
[RFC5649] [RFC5649]
132 0x85 AES unwrap fails test 2, see Section 3 132 0x85 AES unwrap fails test 2, see Section 3
[RFC5649] [RFC5649]
133 0x86 AES unwrap fails test 3, see Section 3 133 0x86 AES unwrap fails test 3, see Section 3
[RFC5649] [RFC5649]
134-175 0x86-0x7F Unassigned 134-175 0x86-0x7F Unassigned
176-191 0xB0-0xBF Reserved for error codes define in use 176-191 0xB0-0xBF Reserved for error codes defined in use
profiles and related to parts of profiles and related to parts of
message outside the AES wrap contents message outside the AES wrap contents
192 0xC0 No keys set 192 0xC0 No keys set
193 0xC1 Referenced key unknown 193 0xC1 Referenced key unknown
194 0xC2 Referenced key known but use flag not set 194 0xC2 Referenced key known but use flag not set
195-255 0xC3-0xFF Reserved 195-255 0xC3-0xFF Reserved
Response Code Notes: Response Code Notes:
Note 1 Message is too short or too long, AES wrapped material is too Note 1 Message is too short or too long, AES wrapped material is too
skipping to change at page 15, line 38 skipping to change at page 15, line 44
long, Padding bytes are not the required value, or similar long, Padding bytes are not the required value, or similar
fundamental vector of fields format problems. fundamental vector of fields format problems.
Note 3 Key is not a valid length for CypherSuite or other internal Note 3 Key is not a valid length for CypherSuite or other internal
checks on key (for example, parity bits in a 64 bit DES key checks on key (for example, parity bits in a 64 bit DES key
(not that you should be using DES)) fail. (not that you should be using DES)) fail.
2.8 No-Op Message 2.8 No-Op Message
The No-Op message is a dummy message intended for use in disguising The No-Op message is a dummy message intended for use in disguising
the metadata of keying message transmissions. It requires no response metadata deducable from keying message transmissions. It requires no
although a recipient can always decided to send a No-Op message to a response although a recipient can always decided to send a No-Op
station from which it has received such a message. message to a station from which it has received such a message.
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Msg Type = 5 | 1 byte | Msg Type = 6 | 1 byte
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Pad2 Length | 1 bytes | Pad2 Length | 1 bytes
+-+-+-+-+-+-+-+-+... +-+-+-+-+-+-+-+-+...
| Padding Pad2 Length bytes | Padding Pad2 Length bytes
+-+-+-+-+-+-+-+-... +-+-+-+-+-+-+-+-...
INTERNET-DRAFT TRILL: Group Keying
Figure 2.5. No-Op Message Inner Structure Figure 2.5. No-Op Message Inner Structure
The Msg Type is set to 6 to indicate a No-Op message. The Msg Type is set to 6 to indicate a No-Op message.
Pad2 Length and Padding are as specified in Section 2.6. It is Pad2 Length and Padding are as specified in Section 2.6. It is
INTERNET-DRAFT TRILL: Group Keying
RECOMMENDED that Pad2 Length in a No-Op message be such as to make RECOMMENDED that Pad2 Length in a No-Op message be such as to make
its length confusable with the length of a Set Key message. its length confusable with the length of a Set Key message.
2.9 General Security Considerations 2.9 General Security Considerations
This section gives some general security considerations of this group This section gives some general security considerations of this group
keying protocol as distinguished from security considerations of a keying protocol as distinguished from security considerations of a
particular use profile. particular use profile.
The method by which the stations in the group discover each other is The method by which the stations in the group discover each other is
skipping to change at page 17, line 11 skipping to change at page 17, line 11
The content value of padding fields in the Group Keying protocol is The content value of padding fields in the Group Keying protocol is
fixed so that it cannot be used as a covert channel. The length of fixed so that it cannot be used as a covert channel. The length of
padding could still be so used. padding could still be so used.
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
3. Extended RBridge Channel Group Keyed Security 3. Extended RBridge Channel Group Keyed Security
This section specifies a profile of the group keying protocol defined This section specifies a profile of the group keying protocol defined
in Section 2. This profile provides shared secret keying to secure in Section 2. This profile provides shared secret keying to secure
multi-destination Extended RBridge Channel messages multi-destination Extended RBridge Channel messages [RFC7978]. The
[ExtendedChannel]. The keys put in place by the group keying keys put in place by the group keying protocol are available for use
protocol are available for use as DTLS pre-shared keys with the DTLS as DTLS pre-shared keys with the DTLS and Composite Security of
and Composite Security of multi-destination Extended RBridge Channel multi-destination Extended RBridge Channel messages as specified in
messages as specified in Section 3.2. Section 3.2.
For this group keying use profile, a group is identified by TRILL For this group keying use profile, a group is identified by TRILL
Data Label (VLAN or FGL [RFC7172]) and consists of the data reachable Data Label (VLAN or FGL [RFC7172]) and consists of the data reachable
[RFC7780] RBridges with interest in that Data Label. GKd is the [RFC7780] RBridges with interest in that Data Label. GKd is the
RBridge in the group that, of those group members supporting the RBridge in the group that, of those group members supporting the
Group Keying Protocol, is the highest priority to be a TRILL Group Keying Protocol, is the highest priority to be a TRILL
distribution tree root. If not all members of the group support the distribution tree root. If not all members of the group support the
Group Keying Protocol, then there are two cases for multi-destination Group Keying Protocol, then there are two cases for multi-destination
Channel Tunnel RBridge Channel messages: Channel Tunnel RBridge Channel messages:
(1) If the sender and at least two other group members support the (1) If the sender and at least two other group members support the
Group Keying Protocol, it SHOULD, for efficiency, send a secured Group Keying Protocol, it SHOULD, for efficiency, send a secured
multi-destination RBridge Channel message to cover the group and multi-destination RBridge Channel message to cover the group and
serially unicast to the group members not supporting the Group serially unicast to the group members not supporting the Group
Keying Protocol. Keying Protocol.
(2) In other cases the sender serially transmits the data to the (2) In other cases the sender serially transmits the data to the
group members using pairwise security. group members using pairwise security.
3.1 Transmission of Group Keying Messages 3.1 Transmission of Group Keying Messages
Keying messages themselves are sent as unicast Extended RBridge Keying messages themselves are sent as unicast Extended RBridge
Channel messages using carrying a Group Keying protocol (see Section Channel messages carrying a Group Keying protocol (see Section 5.2)
4.2) RBridge Channel message. They MUST use DTLS Pairwise or RBridge Channel message. They MUST use DTLS Pairwise or Composite
Composite (STypes 2 or 3) security. (STypes 2 or 3) security.
Fields profile for this Group Keying Use Type is as follows: The RBridge Channel fields profile for this Group Keying Use Type is
as follows:
Priority of Group Keying messages for this SHOULD be 6 unless the Priority of Group Keying messages for this SHOULD be 6 unless the
network manager chooses to use a lower priority after network manager chooses to use a lower priority after
determining that such lower priority group keying messages determining that such lower priority group keying messages
will yield acceptable performance. Priority 7 SHOULD NOT be will yield acceptable performance. Priority 7 SHOULD NOT be
used as it may cause interference with the establishment and used as it may cause interference with the establishment and
maintenance of adjacency. maintenance of adjacency.
Use Type = 1 Use Type = 1
KeyID1 Length = 2, KeyID1 is an [RFC5310] key ID. KeyID1 Length = 2, KeyID1 is an [RFC5310] key ID.
CypherSuiteLng = 2, CypherSuite is the cypher suite used in CypherSuiteLng = 2, CypherSuite is the cypher suite used in
groupcast extended RBridge Channel data messages for the
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
groupcast extended RBridge Channel data messages for the
corresponding KeyID2. This a DTLS [RFC6347] cypher suite. corresponding KeyID2. This a DTLS [RFC6347] cypher suite.
KeyID2 Length = 1, KeyID2 is the index under which a group key is KeyID2 Length = 1, KeyID2 is the index under which a group key is
set. Group keys are, in effect, indexed by this KeyID2 and set. Group keys are, in effect, indexed by this KeyID2 and
the nickname of the GKd as used in the Ingress Nickname the nickname of the GKd as used in the Ingress Nickname
field of the TRILL Header of Group Keying messages. field of the TRILL Header of Group Keying messages.
3.2 Transmission of Protected Multi-destination Data 3.2 Transmission of Protected Multi-destination Data
Protected Extended RBridge Channel [ExtendedChannel] messages are Protected Extended RBridge Channel [RFC7978] messages are multicast
multicast (M bit set to one in the TRILL Header) and set the SType (M bit set to one in the TRILL Header) and set the SType field to a
field to a new value for "Group Secured" (See Section 4.3). The data new value for "Group Secured" (See Section 5.3). The data is
is formatted as one byte of Key ID followed by data formatted as TLS formatted as one byte of Key ID followed by data formatted as TLS 1.2
1.2 [RFC5246] application_data using the cyphersuite and keying [RFC5246] application_data using the cyphersuite and keying material
material stored under the Key ID. stored under the Key ID.
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
4. IANA Considerations 4. TRILL Over IP Group Keyed Security
This section specifies a profile of the group keying protocol defined
in Section 2. This profile provides shared secret keying to secure
TRILL over IP messages [TRILLoverIP]. The keys put in place by the
group keying protocol are available for use as IPSEC keys.
For this group keying use profile, a group is identified by an IP
multicast address and consists of the adjacent [RFC7177] RBridges
reachable with that multicast address. GKd is the RBridge in the
group that, of those group members supporting the Group Keying
Protocol, has the highest priority to be a TRILL distribution tree
root. If not all members of the group support the Group Keying
Protocol, then there are two cases for multi-destination TRILL over
IP messages:
(1) If the sender and at least two other group members support the
Group Keying Protocol, it SHOULD, for efficiency, send a secured
IPSEC message to cover the group and serially unicast to the
group members not supporting the Group Keying Protocol.
(2) In other cases the sender serially transmits the data to the
group members using pairwise security.
4.1 Transmission of Group Keying Messages
tbd
Use Type = 2
tbd
4.2 Transmission of Protected Multi-destination Data
tbd
INTERNET-DRAFT TRILL: Group Keying
5. IANA Considerations
This section gives IANA Considerations. This section gives IANA Considerations.
4.1 Group Keying Protocol 5.1 Group Keying Protocol
IANA is requested to perform the following actions: IANA is requested to perform the following actions:
1. Establish a protocol parameters web page for "Group Keying 1. Establish a protocol parameters web page for "Group Keying
Protocol Parameters" with the initial registries on that page Protocol Parameters" with the initial registries on that page
as specified below in this section. as specified below in this section.
2. Establish a "Message Type" registry on the Group Keying 2. Establish a "Message Type" registry on the Group Keying
Protocol Parameters page as follows: Protocol Parameters page as follows:
skipping to change at page 19, line 33 skipping to change at page 20, line 33
Reference: [this document] Reference: [this document]
Type Description Reference Type Description Reference
------- ----------- --------------- ------- ----------- ---------------
0 Reserved [This document] 0 Reserved [This document]
1 Set Key [This document] 1 Set Key [This document]
2 Use Key [This document] 2 Use Key [This document]
3 Delete Key [This document] 3 Delete Key [This document]
4 Disuse Key [This document] 4 Disuse Key [This document]
5 No-Op [This document] 5 Deleted Key [This document]
6-250 Unassigned 6 No-Op [This document]
7-250 Unassigned
251-254 Reserved for Private Use [This document] 251-254 Reserved for Private Use [This document]
255 Reserved [This document] 255 Reserved [This document]
3. Establish a "Group Keying Use Profile" registry on the Group 3. Establish a "Group Keying Use Profile" registry on the Group
Keying Protocol Parameters page as follows: Keying Protocol Parameters page as follows:
Registration Procedure: IETF Review Registration Procedure: IETF Review
Reference: [This document] Reference: [This document]
Profile Description Reference Profile Description Reference
--------- ----------- --------- --------- ----------- ---------
0 Reserved [This document] 0 Reserved [This document]
1 Extended RBridge Channel [This document] 1 Extended RBridge Channel [This document]
2-250 Unassigned 2 TRILL over IP [This document]
3-250 Unassigned
251-254 Reserved for Private Use [This document] 251-254 Reserved for Private Use [This document]
255 Reserved [This document] 255 Reserved [This document]
4. Establish a "Response Code" registry on the Group Keying
Protocol Parameters page as show below taking entries from the
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
4. Establish a "Response Code" registry on the Group Keying
Protocol Parameters page as show below taking entries from the
Response Code table in Section 2.8.1 above. In the table of Response Code table in Section 2.8.1 above. In the table of
values, the Reference column should be "[This document]" except values, the Reference column should be "[This document]" except
where the Meaning is "Unassigned" or "Reserved". where the Meaning is "Unassigned" or "Reserved".
Registration Procedure: IETF Review Registration Procedure: IETF Review
Reference: [This document] Reference: [This document]
Note: The top two bits of the Response Code indicate a category Note: The top two bits of the Response Code indicate a category
as specified in Section 2.8.1 of [this document]. as specified in Section 2.8.1 of [this document].
Response Response Response Response
Decimal Hex Meaning Reference Decimal Hex Meaning Reference
-------- --------- ----------- --------- -------- --------- ----------- ---------
0 0x00 Success [this document] 0 0x00 Success [this document]
... ... ... ... ... ...
255 0xFF Reserved 255 0xFF Reserved
4.2 Group Keying RBridge Channel Protocol Numbers 5.2 Group Keying RBridge Channel Protocol Numbers
IANA is requested to assign TBD1 as the RBridge Channel protocol IANA is requested to assign TBD1 as the RBridge Channel protocol
numbers, from the range assigned by Standards Action, for use when numbers, from the range assigned by Standards Action, for use when
the "Group Keying" protocol is transmitted over Extended RBridge the "Group Keying" protocol is transmitted over Extended RBridge
Channel messages. Channel messages.
The added RBridge Channel protocols registry entry on the TRILL The added RBridge Channel protocols registry entry on the TRILL
Parameters web page is as follows: Parameters web page is as follows:
Protocol Description Reference Protocol Description Reference
-------- -------------- ------------------ -------- -------------- ------------------
TBD1 Group Keying Section 2 of [this document] TBD1 Group Keying Section 2 of [this document]
4.3 Group Secured Extended RBridge Channel SType 5.3 Group Secured Extended RBridge Channel SType
IANA is requested to assign TBD2 as the Group Secured SType in the IANA is requested to assign TBD2 as the Group Secured SType in the
"Extended RBridge Channel Security Types Subregistry" on the TRILL "Extended RBridge Channel Security Types Subregistry" on the TRILL
Parameters web page as follows: Parameters web page as follows:
SType Description Reference SType Description Reference
----- ------------- ---------- ----- ------------- ----------
TBD2 Group Secured Section 3.2 of [this document] TBD2 Group Secured Section 3.2 of [this document]
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
5. Security Considerations 6. Security Considerations
TBD TBD
See [RFC7457] in connection with TLS and DTLS security. See [RFC7457] in connection with TLS and DTLS security.
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
Normative References Normative References
[RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate [RFC2119] - BBradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 22, line 55 skipping to change at page 23, line 55
and D. Dutt, "Transparent Interconnection of Lots of Links and D. Dutt, "Transparent Interconnection of Lots of Links
(TRILL): Fine-Grained Labeling", RFC 7172, DOI (TRILL): Fine-Grained Labeling", RFC 7172, DOI
10.17487/RFC7172, May 2014, <http://www.rfc- 10.17487/RFC7172, May 2014, <http://www.rfc-
editor.org/info/rfc7172>. editor.org/info/rfc7172>.
[RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt, [RFC7176] - Eastlake 3rd, D., Senevirathne, T., Ghanwani, A., Dutt,
D., and A. Banerjee, "Transparent Interconnection of Lots of D., and A. Banerjee, "Transparent Interconnection of Lots of
Links (TRILL) Use of IS-IS", RFC 7176, May 2014, Links (TRILL) Use of IS-IS", RFC 7176, May 2014,
<http://www.rfc-editor.org/info/rfc7176>. <http://www.rfc-editor.org/info/rfc7176>.
[RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D. [RFC7177] - Eastlake 3rd, D., Perlman, R., Ghanwani, A., Yang, H.,
Ward, "Transparent Interconnection of Lots of Links (TRILL): and V. Manral, "Transparent Interconnection of Lots of Links
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
(TRILL): Adjacency", RFC 7177, DOI 10.17487/RFC7177, May 2014,
<http://www.rfc-editor.org/info/rfc7177>.
[RFC7178] - Eastlake 3rd, D., Manral, V., Li, Y., Aldrin, S., and D.
Ward, "Transparent Interconnection of Lots of Links (TRILL):
RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May RBridge Channel Support", RFC 7178, DOI 10.17487/RFC7178, May
2014, <http://www.rfc-editor.org/info/rfc7178>. 2014, <http://www.rfc-editor.org/info/rfc7178>.
[RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A., [RFC7780] - Eastlake 3rd, D., Zhang, M., Perlman, R., Banerjee, A.,
Ghanwani, A., and S. Gupta, "Transparent Interconnection of Ghanwani, A., and S. Gupta, "Transparent Interconnection of
Lots of Links (TRILL): Clarifications, Corrections, and Lots of Links (TRILL): Clarifications, Corrections, and
Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016, Updates", RFC 7780, DOI 10.17487/RFC7780, February 2016,
<http://www.rfc-editor.org/info/rfc7780>. <http://www.rfc-editor.org/info/rfc7780>.
[ExtendedChannel] - D. Eastlake, M. Umair, Y. Li, "TRILL: RBridge [RFC7978] - Eastlake 3rd, D., Umair, M., and Y. Li, "Transparent
Channel Tunnel Protocol", draft-ietf-trill-channel-tunnel, work Interconnection of Lots of Links (TRILL): RBridge Channel
in progress. Header Extension", RFC 7978, DOI 10.17487/RFC7978, September
2016, <http://www.rfc-editor.org/info/rfc7978>.
[TRILLoverIP] - M. Cullen, D. Eastlake, M. Zhang, D. Zhang,
"Transparent Interconnection of Lots of Links (TRILL) over IP",
draft-ietf-trill-over-ip, work in progress.
Informative References Informative References
[RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash [RFC6234] - Eastlake 3rd, D. and T. Hansen, "US Secure Hash
Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI
10.17487/RFC6234, May 2011, <http://www.rfc- 10.17487/RFC6234, May 2011, <http://www.rfc-
editor.org/info/rfc6234>. editor.org/info/rfc6234>.
[RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing [RFC7457] - Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and Datagram Known Attacks on Transport Layer Security (TLS) and Datagram
TLS (DTLS)", RFC 7457, February 2015, <http://www.rfc- TLS (DTLS)", RFC 7457, February 2015, <http://www.rfc-
editor.org/info/rfc7457>. editor.org/info/rfc7457>.
[TRILLoverIP] - M. Cullen, D. Eastlake, M. Zhang, D. Zhang,
"Transparent Interconnection of Lots of Links (TRILL) over IP",
draft-ietf-trill-over-ip, work in progress.
INTERNET-DRAFT TRILL: Group Keying INTERNET-DRAFT TRILL: Group Keying
Acknowledgements Acknowledgements
The contributions of the following are hereby gratefully The contributions of the following are hereby gratefully
acknowledged: acknowledged:
TBD TBD
The document was prepared in raw nroff. All macros used were defined The document was prepared in raw nroff. All macros used were defined
 End of changes. 61 change blocks. 
122 lines changed or deleted 178 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/