draft-ietf-mpls-in-ip-or-gre-07.txt   draft-ietf-mpls-in-ip-or-gre-08.txt 
Network Working Group Tom Worster Network Working Group Tom Worster
Internet Draft Internet Draft
Expiration Date: September 2004 Expiration Date: December 2004
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
Eric C. Rosen, editor Eric C. Rosen, editor
Cisco Systems, Inc. Cisco Systems, Inc.
March 2004 June 2004
Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE) Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)
draft-ietf-mpls-in-ip-or-gre-07.txt draft-ietf-mpls-in-ip-or-gre-08.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
6 Applicability .......................................... 8 6 Applicability .......................................... 8
7 IANA Considerations .................................... 9 7 IANA Considerations .................................... 9
8 Security Considerations ................................ 9 8 Security Considerations ................................ 9
8.1 Securing the Tunnel Using IPsec ........................ 9 8.1 Securing the Tunnel Using IPsec ........................ 9
8.2 In the Absence of IPsec ................................ 11 8.2 In the Absence of IPsec ................................ 11
9 Acknowledgments ........................................ 12 9 Acknowledgments ........................................ 12
10 Normative References ................................... 12 10 Normative References ................................... 12
11 Informative References ................................. 13 11 Informative References ................................. 13
12 Author Information ..................................... 13 12 Author Information ..................................... 13
13 Intellectual Property Notice ........................... 14 13 Intellectual Property Notice ........................... 14
14 Copyright Notice ....................................... 14 14 Copyright Notice ....................................... 15
1. Specification of Requirements 1. Specification of Requirements
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 RFC 2119. document are to be interpreted as described in RFC 2119.
2. Motivation 2. Motivation
In many applications of MPLS, packets traversing an MPLS backbone In many applications of MPLS, packets traversing an MPLS backbone
skipping to change at page 9, line 32 skipping to change at page 9, line 32
specified encapsulations do not by themselves assure the decapsulator specified encapsulations do not by themselves assure the decapsulator
of the packet's integrity.) A third problem is the possibility that of the packet's integrity.) A third problem is the possibility that
the packet's contents will be seen while the packet is in transit the packet's contents will be seen while the packet is in transit
through the tunnel. (I.e., the specification encapsulations do not through the tunnel. (I.e., the specification encapsulations do not
ensure privacy.) How significant these issues are in practice depends ensure privacy.) How significant these issues are in practice depends
on the security requirements of the applications whose traffic is on the security requirements of the applications whose traffic is
being sent through the tunnel. E.g., lack of privacy for tunneled being sent through the tunnel. E.g., lack of privacy for tunneled
packets is not a significant issue if the applications generating the packets is not a significant issue if the applications generating the
packets do not require privacy. packets do not require privacy.
Because of the different potential security requirements, deployment
scenarios, and performance considerations of different applications
using the described encapsulation mechanism, this specification
defines IPsec support as OPTIONAL. Basic implementation requirements
if IPsec is implemented are described in section 8.1. If IPsec is not
implemented, additional mechanisms may need to be implemented and
deployed. Those are discussed in section 8.2.
8.1. Securing the Tunnel Using IPsec 8.1. Securing the Tunnel Using IPsec
All of these security issues can be avoided if the MPLS-in-IP or All of these security issues can be avoided if the MPLS-in-IP or
MPLS-in-GRE tunnels are secured using IPsec. MPLS-in-GRE tunnels are secured using IPsec. Implementation
requirements defined in this section apply if IPsec is implemented.
When using IPsec, the tunnel head and the tunnel tail should be When using IPsec, the tunnel head and the tunnel tail should be
treated as the endpoints of a Security Association. For this treated as the endpoints of a Security Association. For this
purpose, a single IP address of the tunnel head will be used as the purpose, a single IP address of the tunnel head will be used as the
source IP address, and a single IP address of the tunnel tail will be source IP address, and a single IP address of the tunnel tail will be
used as the destination IP address. The means by which each node used as the destination IP address. The means by which each node
knows the proper address of the other is outside the scope of this knows the proper address of the other is outside the scope of this
document. If a control protocol is used to set up the tunnels (e.g., document. If a control protocol is used to set up the tunnels (e.g.,
to inform one tunnel endpoint of the IP address of the other), the to inform one tunnel endpoint of the IP address of the other), the
control protocol MUST have an authentication mechanism, and this MUST control protocol MUST have an authentication mechanism, and this MUST
skipping to change at page 10, line 36 skipping to change at page 10, line 45
distributed to the tunnel heads of IPsec-secured tunnels. Labels in distributed to the tunnel heads of IPsec-secured tunnels. Labels in
this set MUST NOT be distributed by the tunnel tail to any LSP this set MUST NOT be distributed by the tunnel tail to any LSP
adjacencies other than those which are tunnel heads of IPsec-secured adjacencies other than those which are tunnel heads of IPsec-secured
tunnels. If an MPLS packet is received without an IPsec tunnels. If an MPLS packet is received without an IPsec
encapsulation, and if its topmost label is in this set, then the encapsulation, and if its topmost label is in this set, then the
packet MUST be discarded. packet MUST be discarded.
An IPsec-secured MPLS-in-IP or MPLS-in-GRE tunnel MUST provide An IPsec-secured MPLS-in-IP or MPLS-in-GRE tunnel MUST provide
authentication and integrity. (Note that the authentication and authentication and integrity. (Note that the authentication and
integrity will apply to the entire MPLS packet, including the MPLS integrity will apply to the entire MPLS packet, including the MPLS
label stack.) Whether additional security, i.e., confidentiality label stack.) Thus, the implementation MUST support ESP will null
and/or replay protection, is required will depend upon the needs of encryption. ESP with encryption MAY be supported if a source
the applications whose data is being sent through the tunnel. If requires confidentiality. If ESP is used, the tunnel tail MUST check
confidentiality is not needed, then either the AH or the ESP that the source IP address of any packet that is received on a given
protocols MAY be used. If confidentiality is needed, the ESP SA is the one that is expected.
protocol MUST be used, and the payload must be encrypted. If ESP is
used, the tunnel tail MUST check that the source IP address of any
packet that is received on a given SA is the one that is expected.
Key distribution may be done either manually, or automatically by Key distribution may be done either manually, or automatically by
means of IKE [RFC2409]. Manual key distribution is much simpler, but means of IKE [RFC2409]. Manual keying MUST be supported. If
also less scalable, than automatic key distribution. Which method of automatic keying is implemented, IKE in main mode with preshared keys
key distribution is appropriate for a particular tunnel thus needs to MUST be supported. A particular application may escalate this
be carefully considered by the administrator (or pair of requirement and request implementation of automatic keying.
administrators) responsible for the tunnel endpoints. If replay
protection is regarded as necessary for a particular tunnel, Manual key distribution is much simpler, but also less scalable, than
automatic key distribution MUST be used. automatic key distribution. Which method of key distribution is
appropriate for a particular tunnel thus needs to be carefully
considered by the administrator (or pair of administrators)
responsible for the tunnel endpoints. If replay protection is
regarded as necessary for a particular tunnel, automatic key
distribution should be configured.
If the MPLS-in-IP encapsulation is being used, the selectors If the MPLS-in-IP encapsulation is being used, the selectors
associated with the SA would be the source and destination addresses associated with the SA would be the source and destination addresses
mentioned above, plus the IP protocol number specified in section 3. mentioned above, plus the IP protocol number specified in section 3.
If it is desired to separately secure multiple MPLS-in-IP tunnels If it is desired to separately secure multiple MPLS-in-IP tunnels
between a given pair of nodes, each tunnel must have unique pair of between a given pair of nodes, each tunnel must have unique pair of
IP addresses. IP addresses.
If the MPLS-in-GRE encapsulation is being used, the selectors If the MPLS-in-GRE encapsulation is being used, the selectors
associated with the SA would be the the source and destination associated with the SA would be the the source and destination
skipping to change at page 12, line 15 skipping to change at page 12, line 20
9. Acknowledgments 9. Acknowledgments
This specification combines prior work on encapsulating MPLS in IP, This specification combines prior work on encapsulating MPLS in IP,
by Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew by Tom Worster, Paul Doolan, Yasuhiro Katsube, Tom K. Johnson, Andrew
G. Malis, and Rick Wilder, with prior work on encapsulating MPLS in G. Malis, and Rick Wilder, with prior work on encapsulating MPLS in
GRE, by Yakov Rekhter, Daniel Tappan, and Eric Rosen. The current GRE, by Yakov Rekhter, Daniel Tappan, and Eric Rosen. The current
authors wish to thank all these authors for their contribution. authors wish to thank all these authors for their contribution.
Many people have made valuable comments and corrections, including Many people have made valuable comments and corrections, including
Rahul Aggarwal, Scott Bradner, Alex Conta, Mark Duffy, Francois Le Rahul Aggarwal, Scott Bradner, Alex Conta, Mark Duffy, Francois Le
Feucheur, Allison Mankin, Thomas Narten, and Pekka Savola. Feucheur, Allison Mankin, Thomas Narten, Pekka Savola, and Alex
Zinin.
10. Normative References 10. Normative References
[RFC791] "Internet Protocol," J. Postel, Sep 1981 [RFC791] "Internet Protocol," J. Postel, Sep 1981
[RFC792] "Internet Control Message Protocol", J. Postel, Sept 1981 [RFC792] "Internet Control Message Protocol", J. Postel, Sept 1981
[RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November [RFC1191] "Path MTU Discovery", J.C. Mogul, S.E. Deering, November
1990 1990
 End of changes. 

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