draft-ietf-l3vpn-ipsec-2547-04.txt   draft-ietf-l3vpn-ipsec-2547-05.txt 
Network Working Group Eric C. Rosen Network Working Group Eric C. Rosen
Internet Draft Cisco Systems, Inc. Internet Draft Cisco Systems, Inc.
Expiration Date: December 2005 Expiration Date: February 2006
Jeremy De Clercq Jeremy De Clercq
Olivier Paridaens Olivier Paridaens
Yves T'Joens Yves T'Joens
Alcatel Alcatel
Chandru Sargor Chandru Sargor
June 2005 August 2005
Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs Architecture for the Use of PE-PE IPsec Tunnels in BGP/MPLS IP VPNs
draft-ietf-l3vpn-ipsec-2547-04.txt draft-ietf-l3vpn-ipsec-2547-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 2, line 39 skipping to change at page 2, line 39
1.6 Conclusion ............................................. 7 1.6 Conclusion ............................................. 7
2 Specification .......................................... 7 2 Specification .......................................... 7
2.1 Technical Approach ..................................... 7 2.1 Technical Approach ..................................... 7
2.2 Selecting the Security Policy .......................... 8 2.2 Selecting the Security Policy .......................... 8
2.3 BGP Label, Route, and Policy Distribution .............. 9 2.3 BGP Label, Route, and Policy Distribution .............. 9
2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10 2.4 MPLS-in-IP/GRE Encapsulation by Ingress PE ............. 10
2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11 2.5 MPLS-in-IP vs. MPLS-in-GRE ............................. 11
2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11 2.6 PE-PE IPsec (Application of IPsec by Ingress PE) ....... 11
2.7 Application of IPsec by Egress PE ...................... 13 2.7 Application of IPsec by Egress PE ...................... 13
3 Comparison with Using Part of SPI Field as a Label ..... 15 3 Comparison with Using Part of SPI Field as a Label ..... 15
4 Security Considerations ................................ 15 4 Security Considerations ................................ 16
5 IANA Considerations .................................... 16 5 IANA Considerations .................................... 16
6 Acknowledgments ........................................ 16 6 Acknowledgments ........................................ 16
7 Authors' Addresses ..................................... 16 7 Authors' Addresses ..................................... 16
8 Normative References ................................... 17 8 Normative References ................................... 17
9 Informative References ................................. 17 9 Informative References ................................. 17
10 Full Copyright Statement ............................... 17 10 Full Copyright Statement ............................... 17
11 Intellectual Property .................................. 18 11 Intellectual Property .................................. 18
1. Introduction 1. Introduction
skipping to change at page 15, line 5 skipping to change at page 14, line 47
table that is used for packets that have been removed from IPsec SAs. table that is used for packets that have been removed from IPsec SAs.
Certain VPN-IP routes will be exported to certain SPs, but not to Certain VPN-IP routes will be exported to certain SPs, but not to
others. Security can thus be improved by having one label lookup others. Security can thus be improved by having one label lookup
table for each such SP. The IPsec module would then have to say, for table for each such SP. The IPsec module would then have to say, for
each packet, which SP it came from. Given a proper certificate each packet, which SP it came from. Given a proper certificate
authority infrastructure this can be inferred by the IPsec module authority infrastructure this can be inferred by the IPsec module
from the information which the IKE procedure makes available to it. from the information which the IKE procedure makes available to it.
Of course, all this presupposes that the VPN code is capable of Of course, all this presupposes that the VPN code is capable of
properly populating the various lookup tables. properly populating the various lookup tables.
It should be noted that when two PEs negotiate (via IKE) an SA, they
specify the traffic to be covered, identifying the traffic with the
triple <source address, destination address, protocol>. This means
that if any MPLS-in-IP/GRE traffic between the two addresses is sent
through the SA, then all MPLS-in-IP/GRE traffic between the two
addresses is sent through the SA. If it is desired that some such
traffic be sent in the clear, then it may be necessary to use a
different source and/or destination address for the cleartext traffic
than is used for the protected traffic.
3. Comparison with Using Part of SPI Field as a Label 3. Comparison with Using Part of SPI Field as a Label
An alternative methodology that achieves similar results is the one An alternative methodology that achieves similar results is the one
described in [VPN-SPI]. The proposal described above was in fact described in [VPN-SPI]. The proposal described above was in fact
inspired by that draft, and arose as a proposed improvement to it. inspired by that draft, and arose as a proposed improvement to it.
In the current proposal, IPsec transport mode is applied to an MPLS- In the current proposal, IPsec transport mode is applied to an MPLS-
in-IP encapsulation, where the MPLS-in-IP encapsulation carries the in-IP encapsulation, where the MPLS-in-IP encapsulation carries the
BGP-distributed labels of [RFC2547bis]. In [VPN-SPI], there is no BGP-distributed labels of [RFC2547bis]. In [VPN-SPI], there is no
MPLS-in-IP encapsulation. Rather: MPLS-in-IP encapsulation. Rather:
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/