draft-ietf-idr-sdwan-edge-discovery-00.txt   draft-ietf-idr-sdwan-edge-discovery-01.txt 
Network Working Group L. Dunbar Network Working Group L. Dunbar
Internet Draft Futurewei Internet Draft Futurewei
Intended status: Standard S. Hares Intended status: Standard S. Hares
Expires: February 31, 2022 Hickory Hill Consulting Expires: September 5, 2022 Hickory Hill Consulting
R. Raszuk R. Raszuk
NTT Network Innovations NTT Network Innovations
K. Majumdar K. Majumdar
CommScope CommScope
Gyan Mishra Gyan Mishra
Verizon Verizon
August 31, 2021 March 5, 2022
BGP UPDATE for SDWAN Edge Discovery BGP UPDATE for SDWAN Edge Discovery
draft-ietf-idr-sdwan-edge-discovery-00 draft-ietf-idr-sdwan-edge-discovery-01
Abstract Abstract
The document describes the encoding of BGP UPDATE messages for the The document describes the encoding of BGP UPDATE messages for the
SDWAN edge node discovery. SDWAN edge node discovery.
In the context of this document, BGP Route Reflector (RR) is the In the context of this document, BGP Route Reflector (RR) is the
component of the SDWAN Controller that receives the BGP UPDATE from component of the SDWAN Controller that receives the BGP UPDATE from
SDWAN edges and in turns propagates the information to the intended SDWAN edges and in turns propagates the information to the intended
peers that are authorized to communicate via the SDWAN overlay peers that are authorized to communicate via the SDWAN overlay
skipping to change at page 2, line 10 skipping to change at page 2, line 10
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on Dec 30, 2020. This Internet-Draft will expire on Dec 31, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 5, line 18 skipping to change at page 5, line 18
VPN Virtual Private Network. VPN Virtual Private Network.
VRF VPN Routing and Forwarding instance. VRF VPN Routing and Forwarding instance.
WAN Wide Area Network. WAN Wide Area Network.
3. Framework of SDWAN Edge Discovery 3. Framework of SDWAN Edge Discovery
3.1. The Objectives of SDWAN Edge Discovery 3.1. The Objectives of SDWAN Edge Discovery
The objectives of SDWAN edge discovery are for a SDWAN edge node to The objectives of SDWAN edge discovery are for an SDWAN edge node to
discover its authorized peers and their associated properties for discover its authorized peers and their associated properties to
its attached clients' traffic to communicate. The attributes to be establish secure tunnels. The attributes to be propagated includes:
propagated includes the SDWAN (client) VPNs supported, the attached
routes under specific SDWAN VPNs, and the properties of the underlay - the SDWAN (client) VPNs information,
networks over which the client routes can be carried. - the attached routes under the SDWAN VPNs,
- the properties of the underlay networks over which the client
routes can be carried, and potentially more.
Some SDWAN peers are connected by both trusted VPNs and untrusted Some SDWAN peers are connected by both trusted VPNs and untrusted
public networks. Some SDWAN peers are connected only by untrusted public networks. Some SDWAN peers are connected only by untrusted
public networks. For the portion over untrusted networks, IPsec public networks. For the traffic over untrusted networks, IPsec
Security Associations (IPsec SA) have to be established and Security Associations (IPsec SA) must be established and maintained.
maintained. If an edge node has network ports behind a NAT, the NAT If an edge node has network ports behind a NAT, the NAT properties
properties needs to be discovered by authorized SDWAN peers. need to be discovered by the authorized SDWAN peers.
Just like any VPN networks, the attached client's routes belonging Like any VPN networks, the attached client's routes belonging to
to specific SDWAN VPNs can only be exchanged with the SDWAN peer specific SDWAN VPNs can only be exchanged with the SDWAN peer nodes
nodes that are authorized to communicate. authorized to communicate.
3.2. Comparing with Pure IPsec VPN 3.2. Comparing with Pure IPsec VPN
A pure IPsec VPN has IPsec tunnels connecting all edge nodes via A pure IPsec VPN has IPsec tunnels connecting all edge nodes over
public internet; it therefore requires stringent authentication and public networks. Therefore, it requires stringent authentication and
authorization (i.e. IKE Phase 1) before other properties of IPsec SA authorization (i.e., IKE Phase 1) before other properties of IPsec
can be exchanged. The IPsec Security Association (SA) between two SA can be exchanged. The IPsec Security Association (SA) between two
untrusted nodes typically requires the following configurations and untrusted nodes typically requires the following configurations and
message exchanges: message exchanges:
- IPsec IKE to authenticate with each other - IPsec IKE to authenticate with each other
- Establish IPsec SA - Establish IPsec SA
o Local key configuration o Local key configuration
o Remote Peer address (192.10.0.10<->172.0.01) o Remote Peer address (192.10.0.10<->172.0.01)
o IKEv2 Proposal directly sent to peer o IKEv2 Proposal directly sent to peer
o Encryption method, Integrity sha512 o Encryption method, Integrity sha512
o Transform set o Transform set
- Attached client prefixes discovery - Attached client prefixes discovery
o By running routing protocol within each IPsec SA o By running routing protocol within each IPsec SA
o If multiple IPsec SAs between two peer nodes are o If multiple IPsec SAs between two peer nodes are
established to achieve load sharing, each IPsec tunnel established to achieve load sharing, each IPsec tunnel
needs to run its own routing protocol to exchange client needs to run its own routing protocol to exchange client
routes attached to the edges. routes attached to the edges.
- Access List or Traffic Selector) - Access List or Traffic Selector)
o Permit Local-IP1, Remote-IP2 o Permit Local-IP1, Remote-IP2
In a BGP controlled SDWAN network, e.g. a MPLS based network adding In a BGP-controlled SDWAN network over hybrid MPLS VPN and public
short-term capacity over Internet using IPsec, there are secure internet underlay networks, all edge nodes and RRs are already
connection between edge nodes and RR, via private path, TLS, DTLS, connected by private VPN paths. The RRs have the policies to manage
etc. The authentication of peer nodes is managed by the RR. More the authentication of all peer nodes. More importantly, when an edge
importantly, when an edge node needs to establish multiple IPsec node needs to establish multiple IPsec tunnels to many edge nodes,
tunnels to many different edge nodes, all the management information all the management information can be multiplexed into the secure
can be multiplexed into the secure management tunnel between RR and management tunnel between RR and the edge node. Therefore, the
the edge node. Therefore, there is reduced amount of authentication amount of authentication in a BGP-Controlled SDWAN network can be
in a BGP Controlled SDWAN network. significantly reduced.
Client VPNs are configured via VRFs, just like the configuration of Client VPNs are configured via VRFs, just like the configuration of
the existing MPLS VPN. The IPsec equivalent traffic selectors for the existing MPLS VPN. The IPsec equivalent traffic selectors for
local and remote routes is achieved by importing/exporting VPN Route local and remote routes are achieved by importing/exporting VPN
Targets. The binding of client routes to IPsec SA is dictated by Route Targets. The binding of client routes to IPsec SA is dictated
policies. As the result, the IPsec configuration for a BGP by policies. As a result, the IPsec configuration for a BGP
controlled SDWAN (with mixed MPLS VPN) can be simplified as the controlled SDWAN (with mixed MPLS VPN) can be simplified as the
following: following:
- The SDWAN controller has authority to authenticate edges and - The SDWAN controller has the authority to authenticate edges
peers. Remote Peer association is controlled by the SDWAN and peers. Remote Peer association is controlled by the SDWAN
Controller (RR) Controller (RR)
- The IKEv2 proposals, including the IPsec Transform set, can - The IKEv2 proposals, including the IPsec Transform set, can
be sent directly to peers or incorporated in a BGP UPDATE. be sent directly to peers or incorporated in a BGP UPDATE.
- BGP UPDATE: Announces the client route reachability for all - BGP UPDATE: Announces the client route reachability for all
permitted parallel tunnels/paths. permitted parallel tunnels/paths.
o No need to run multiple routing protocols in each IPsec o There is no need to run multiple routing protocols in
tunnel. each IPsec tunnel.
- Importing/exporting Route Targets under each client VPN (VRF) - Importing/exporting Route Targets under each client VPN (VRF)
achieves the traffic selection (or permission) among clients' achieves the traffic selection (or permission) among clients'
routes attached to multiple edge nodes. routes attached to multiple edge nodes.
3.3. Client Route UPDATE and Hybrid Underlay Tunnel UPDATE 3.3. Client Route UPDATE and Hybrid Underlay Tunnel UPDATE
As described in [SDWAN-BGP-USAGE], two separate BGP UPDATE messages As described in [SDWAN-BGP-USAGE], two separate BGP UPDATE messages
are used for SDWAN Edge Discovery: are used for SDWAN Edge Discovery:
- UPDATE U1 for advertising the attached client routes, - UPDATE U1 for advertising the attached client routes,
This UPDATE is exactly the same as the BGP edge client route This UPDATE is precisely the same as the BGP edge client route
UDPDATE. It uses the Encapsulation Extended Community and the UPDATE. It uses the Encapsulation Extended Community and the
Color Extended Community to link with the Underlay Tunnels Color Extended Community to link with the Underlay Tunnels
UPDATE Message as specified by the section 8 of [RFC9012]. UPDATE Message as specified in section 8 of [RFC9012].
A new Tunnel Type (SDWAN-Hybrid) is added and used by the A new Tunnel Type (SDWAN-Hybrid) is added and used by the
Encapsulation Extended Community or the Tunnel-Encap Path Encapsulation Extended Community or the Tunnel-Encap Path
Attribute [RFC9012] to indicate mixed underlay networks. Attribute [RFC9012] to indicate mixed underlay networks.
- UPDATE U2 advertises the properties of the various tunnels, - UPDATE U2 advertises the properties of the various tunnels,
including IPsec, terminated at the edge node. including IPsec, terminated at the edge node.
This UPDATE is for an edge node to advertise the properties of This UPDATE is for an edge node to advertise the properties of
directly attached underlay networks, including the NAT directly attached underlay networks, including the NAT
information, pre-configured IPsec SA identifiers, and/or the information, pre-configured IPsec SA identifiers, and/or the
skipping to change at page 8, line 33 skipping to change at page 8, line 33
UDPATE U1: UDPATE U1:
Extended community: RT for SDWAN VPN 1 Extended community: RT for SDWAN VPN 1
NLRI: AFI=? & SAFI = 1/1 NLRI: AFI=? & SAFI = 1/1
Prefix: 10.1.1.x; 20.1.1.x Prefix: 10.1.1.x; 20.1.1.x
NextHop: 2.2.2.2 (C-PE2) NextHop: 2.2.2.2 (C-PE2)
Encapsulation Extended Community: tunnel-type=SDWAN-Hybrid Encapsulation Extended Community: tunnel-type=SDWAN-Hybrid
Color Extended Community: RED Color Extended Community: RED
The UPDATE U1 is recursively resolved to the UPDATE U2 which The UPDATE U1 is recursively resolved to the UPDATE U2 which
specifies the detailed hybrid WAN underlay Tunnels terminated at the specifies the detailed hybrid WAN underlay tunnels terminated at the
C-PE2: C-PE2:
UPDATE U2: UPDATE U2:
NLRI: SAFI = SDWAN-Hybrid NLRI: SAFI = SDWAN-Hybrid
(With Color RED encoded in the NLRI Site-Property field) (With Color RED encoded in the NLRI Site-Property field)
Prefix: 2.2.2.2 Prefix: 2.2.2.2
Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid] Tunnel encapsulation Path Attribute [type=SDWAN-Hybrid]
IPSec SA for 192.0.0.1 IPSec SA for 192.0.0.1
Tunnel-End-Point Sub-TLV for 192.0.0.1 [Tunnel-encap] Tunnel-End-Point Sub-TLV for 192.0.0.1 [Tunnel-encap]
skipping to change at page 9, line 16 skipping to change at page 9, line 16
Tunnel Encap Attr MPLS-in-GRE [type=SDWAN-Hybrid] Tunnel Encap Attr MPLS-in-GRE [type=SDWAN-Hybrid]
Sub-TLV for MPLS-in-GRE [Section 3.2.6 of Tunnel-encap] Sub-TLV for MPLS-in-GRE [Section 3.2.6 of Tunnel-encap]
Note: [RFC9012] Section 11 specifies that each Tunnel Encap Note: [RFC9012] Section 11 specifies that each Tunnel Encap
Attribute can only have one Tunnel-End-Point sub-TLV. Therefore, two Attribute can only have one Tunnel-End-Point sub-TLV. Therefore, two
separate Tunnel Encap Attributes are needed to indicate that the separate Tunnel Encap Attributes are needed to indicate that the
client routes can be carried by either one. client routes can be carried by either one.
3.4. Edge Node Discovery 3.4. Edge Node Discovery
The basic scheme of SDWAN Edge node discovery using BGP consists of The basic scheme of SDWAN edge node discovery using BGP consists of
the following: the following:
- Secure connection to a SDWAN controller (i.e. RR in this - Secure connection to a SDWAN controller (i.e., RR in this
context): context):
For a SDWAN edge with both MPLS and IPsec path, the edge node For an SDWAN edge with both MPLS and IPsec paths, the edge node
should already have secure connection to its controller, i.e. should already have a secure connection to its controller,
RR in this context. For a remote SDWAN edge that is only i.e., RR in this context. For an SDWAN edge that is only
accessible via Internet, the SDWAN edge node, upon power up, accessible via Internet, the SDWAN edge, upon power-up,
establishes a secure tunnel (such as TLS or SSL) with the SDWAN establishes a secure tunnel (such as TLS or SSL) with the SDWAN
central controller whose address is preconfigured on the edge central controller whose address is preconfigured on the edge
node. The central controller will inform the edge node of its node. The central controller informs the edge node of its local
local RR. The edge node will establish a transport layer secure RR. The edge node then establishes a transport layer secure
session with the RR (such as TLS or SSL). session with the RR (such as TLS or SSL).
- The Edge node will advertise its own properties to its - The Edge node will advertise its own properties to its
designated RR via the secure connection. designated RR via the secure connection.
- The RR propagates the received information to the authorized - The RR propagates the received information to the authorized
peers. peers.
- The authorized peers can establish the secure data channels - The authorized peers can establish the secure data channels
(IPsec) and exchange more information among each other. (IPsec) and exchange more information among each other.
For an SDWAN deployment with multiple RRs, it is assumed that there For an SDWAN deployment with multiple RRs, it is assumed that there
are secure connections among those RRs. How secure connections being are secure connections among those RRs. How secure connections are
established among those RRs is the out of the scope of this established among those RRs is out of the scope of this document.
document. The existing BGP UPDATE propagation mechanisms control the The existing BGP UPDATE propagation mechanisms control the edge
edge properties propagation among the RRs. properties propagation among the RRs.
For some special environments where the communication to RR are For some environments where the communication to RR is highly
highly secured, [RFC9016] IKE-less can be deployed to simplify IPsec secured, [RFC9016] IKE-less can be deployed to simplify IPsec SA
SA establishment among edge nodes. establishment among edge nodes.
4. BGP UPDATE to Support SDWAN Segmentation 4. BGP UPDATE to Support SDWAN Segmentation
4.1. SDWAN Segmentation, SDWAN Virtual Topology and Client VPN 4.1. SDWAN Segmentation, SDWAN Virtual Topology and Client VPN
In SDWAN deployment, "SDWAN Segmentation" is a frequently used term, In SDWAN deployment, "SDWAN Segmentation" is a frequently used term,
referring to partitioning a network to multiple sub-networks, just referring to partitioning a network to multiple sub-networks, just
as MPLS VPN does. "SDWAN Segmentation" is achieved by creating SDWAN as MPLS VPN does. "SDWAN Segmentation" is achieved by creating SDWAN
virtual topologies and SDWAN VPNs. A SDWAN virtual topology consists virtual topologies and SDWAN VPNs. An SDWAN virtual topology
of a set of edge nodes and the tunnels, including both IPsec tunnels consists of a set of edge nodes and the tunnels (a.k.a. underlay
and/or MPLS VPN tunnels, interconnecting those edge nodes. paths), including both IPsec tunnels and/or MPLS VPN tunnels,
interconnecting those edge nodes.
An SDWAN VPN is the same as a client VPN, which is configured in the An SDWAN VPN is the same as a client VPN, which is configured in the
same way as the VRFs on PEs of a MPLS VPN. One SDWAN client VPN can same way as the VRFs on PEs of an MPLS VPN. One SDWAN client VPN can
be mapped to one or multiple SD-WAN virtual topologies. How a Client be mapped to multiple SD-WAN virtual topologies. SDWAN Controller
VPN is mapped to a SDWAN virtual topology is governed by policies governs the policies of mapping a client VPN to SDWAN virtual
from the SDWAN controller. topologies.
Each SDWAN edge node may need to support multiple VPNs. Just as a Each SDWAN edge node may need to support multiple VPNs. Just as a
Route Target is used to distinguish different MPLS VPNs, an SDWAN Route Target is used to distinguish different MPLS VPNs, an SDWAN
VPN ID is used to differentiate the SDWAN VPNs. For example, in the VPN ID is used to differentiate the SDWAN VPNs. For example, in the
picture below, the "Payment-Flow" on C-PE2 is only mapped to the picture below, the "Payment-Flow" on C-PE2 is only mapped to the
virtual topology of C-PEs to/from Payment Gateway, whereas other virtual topology of C-PEs to/from Payment Gateway, whereas other
flows can be mapped to a multipoint to multipoint virtual topology. flows can be mapped to a multipoint-to-multipoint virtual topology.
+---+ +---+
+--------------|RR |----------+ +--------------|RR |----------+
/ Untrusted +-+-+ \ / Untrusted +-+-+ \
/ \ / \
/ \ / \
+---------+ MPLS Path +-------+ +---------+ MPLS Path +-------+
11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x 11.1.1.x| C-PE1 A1-------------------------------B1 C-PE2 |10.1.1.x
| | | | | | | |
21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x 21.1.1.x| A2(192.10.0.10)------( 192.0.0.1)B2 |20.1.1.x
skipping to change at page 18, line 39 skipping to change at page 18, line 39
Through Network Address Translation [RFC3489]) to get the NAT Through Network Address Translation [RFC3489]) to get the NAT
properties, the public IP address and the Public Port number to pass properties, the public IP address and the Public Port number to pass
to peers. to peers.
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Port Ext Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R| |Port Ext Type | EncapExt subTLV Length |I|O|R|R|R|R|R|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT Type | Encap-Type |Trans networkID| RD ID | | NAT Type | Encap-Type |Trans networkID| RD ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address | | Local IP Address |
32-bits for IPv4, 128-bits for Ipv6 32-bits for IPv4, 128-bits for Ipv6
~~~~~~~~~~~~ ~~~~~~~~~~~~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port | | Local Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public IP | | Public IP |
32-bits for IPv4, 128-bits for Ipv6 32-bits for IPv4, 128-bits for Ipv6
~~~~~~~~~~~~ ~~~~~~~~~~~~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 31 skipping to change at page 23, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPsec-simType |IPsecSA Length | Flag | |IPsec-simType |IPsecSA Length | Flag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform | Mode | AH algorithms |ESP algorithms | | Transform | Mode | AH algorithms |ESP algorithms |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ReKey Counter (SPI) | | ReKey Counter (SPI) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key1 length | Public Key ~ | key1 length | Public Key ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key2 length | Nonce ~ | key2 length | Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration | | Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where: Where:
o IPsec-SimType: The type value has to be between 128~255 because o IPsec-SimType: The type value has to be between 128~255 because
IPsec-SA subTLV needs 2 bytes for length to carry the needed IPsec-SA subTLV needs 2 bytes for length to carry the needed
information. information.
o IPsec-SA subTLV Length (2 Byte): 25 (or more) o IPsec-SA subTLV Length (2 Byte): 25 (or more)
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags. None are defined at this stage. Flags
 End of changes. 26 change blocks. 
66 lines changed or deleted 69 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/