idnits 2.17.00 (12 Aug 2021) /tmp/idnits2241/draft-stein-pwe3-sec-req-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 317. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 28, 2007) is 5554 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. '2') (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 4447 (ref. '5') (Obsoleted by RFC 8077) == Outdated reference: draft-ietf-mpls-ecmp-bcp has been published as RFC 4928 == Outdated reference: A later version (-01) exists of draft-fang-mpls-gmpls-security-framework-00 -- No information found for draft-draft-stein-pwe3-pwsec - is the name correct? Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y(J). Stein 3 Internet-Draft RAD Data Communications 4 Intended status: Informational Feb 28, 2007 5 Expires: September 1, 2007 7 Requirements for PW Security 8 draft-stein-pwe3-sec-req-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 1, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 To date IETF's security suite has been entirely IP-centric, IPsec 42 only being applicable to IP packets. This document addresses 43 security requirements for MPLS pseudowires. We investigate security 44 considerations arising from the PWE3 architecture, and discuss 45 example threats, authentication, and confidentiality. 47 1. Introduction 49 Although the IP suite is obviously its main focus, the IETF has 50 standardized other protocols, notably MPLS [1] and MPLS pseudowires 51 (PWs) [3]. On the other hand, IETF's security suite is entirely IP- 52 centric, IPsec only being applicable to IP packets. Security aspects 53 of MPLS networks have been addressed in various RFCs, and PPVPN 54 security is been discussed in [4]; work is in progress on an MPLS/ 55 GMPLS security framework [7]. Security considerations of the MPLS 56 control plane will most likely be applicable to the PWE3 control 57 protocol [5] as well. On the other hand security of the user plane 58 for non-IP traffic such as PWs has not yet been addressed in the 59 IETF. 61 The PWE3 architecture [3] defines a pseudowire (PW) connecting 62 customer networks over a provider network. The customer networks run 63 a native service, which may be Ethernet, ATM, frame relay, TDM, etc. 64 On both sides of the PW a customer edge (CE) connects to a provider 65 edge (PE) via an attachment circuit (AC). The PW itself is a tunnel 66 that transports the native service data across the provider network, 67 here assumed to be based on MPLS. PW tunnels are set up using the 68 PWE control protocol based on LDP [2]. 70 PW packets contain at least one MPLS label (the PW label) and may 71 contain one or more MPLS tunnel labels. After the label stack there 72 is a four-byte control word (which is optional for some PW types), 73 followed by the native service payload. It must be stressed that 74 encapsulation of MPLS PW packets in IP for the purpose of enabling 75 use of IPsec mechanisms is not a valid option. 77 For the purpose of the present discussion, the customer networks will 78 be considered walled gardens, under the control of the customer. The 79 provider network is under the control of the provider, but accessible 80 to multiple customers. The customer expects the provider to ensure 81 that its data traversing the provider's network be afforded security 82 similar to that of a (virtual) connection of the native service. 84 The following will be considered explicitly out-of-scope of the 85 present treatment: 86 security considerations of the customer networks, 87 security considerations of the attachment circuits, 88 any security considerations that would exist were the customer 89 networks connected via native service links, 90 security considerations common to all MPLS networks. 92 The following is a nonexhaustive list of threats to be considered: 94 unauthorized setting up a PW (e.g. to gain access to a customer 95 network), 96 unauthorized tearing down of a PW (thus causing denial of 97 service), 98 malicious rerouting of a PW, 99 forking of a PW to snoop PW packets, 100 unauthorized on-route snooping of PW packets, 101 traffic analysis of PW connectivity, 102 unauthorized insertion of PW packets, 103 unauthorized modification of PW packets, 104 unauthorized deletion of PW packets, 105 replay of PW packets, 106 denial of service or significantly impacting PW service quality. 107 These threats are not mutually exclusive, for example, rerouting can 108 be used for snooping or insertion/deletion/replay, etc. 110 Special considerations arising for MS-PWs are for further study. 112 2. PW-specific Security Weaknesses and Strengths 114 The PW user plane suffers from the following inherent security 115 weaknesses: 116 the PW label is the only identifier in the packet (there is no 117 authenticatable source address, cookies, etc.), 118 hence it is relatively easy to introduce seemingly valid foreign 119 packets, 120 the control word sequence number processing algorithm is 121 susceptible to a DoS attack (the sequence number processing 122 algorithm can cause dropping of late packets, so inserting a 123 single future packet can cause a large number of legitimate 124 packets to be discarded). 125 VPLS services built on Ethernet PWs and multisegment PWs introduce 126 additional problems. 128 Even without the ability to observe PW packets, guessing a valid PW 129 label is not difficult. Many implementations start by assigning low 130 PW labels, and thus a small number will usually correspond to a valid 131 PW label. In any case there is no penalty to incorrect guessing, and 132 if one can inject one thousand PW packets per second, then one 133 exhausts the entire PW label space in about fifteen minutes. 135 The PWE control protocol introduces its own weaknesses: 136 no (secure) peer autodiscovery technique has been standardized, 137 PE authentication is not mandated, so an intruder can potentially 138 impersonate a PE, 139 after impersonating a PE, unauthorized PWs may be set up, 140 consuming resources and perhaps allowing access to user networks, 141 similarly, desired PWs may be torn down, giving rise to denial of 142 service. 144 Despite these weaknesses, PWs have the following advantages: 145 the most obvious attacks require compromising edge or core routers 146 (although not necessarily those along PW path), 147 adequate protection of the control plane messaging is sufficient 148 to rule out many attacks, 149 PEs are usually configured to reject MPLS packets from the outside 150 the service provider network, thus ruling out insertion of PW 151 packets from the outside (since IP packets can not masquerade as 152 PW packets). 154 3. Example Attacks 156 A PW man-in-the-middle occurs when an impostor causes two consecutive 157 PWs to be set up instead of one, and stitches them at a provider 158 router of which he has gained control. Such an impostor can then 159 snoop, delete, insert, and change, PW packets. This is different 160 from an MPLS man-in-the-middle attack, which results from an impostor 161 compromising a provider LSR somewhere along the PW path. This latter 162 attack can also compromise PW security, but must be dealt with as an 163 MPLS attack, and is out of scope here. 165 In another scenario the attack involves compromising a forwarding 166 device (router or Ethernet switch) that is not part of the PW path. 167 In this case the attack exploits the MPLS mechanism for tunnel 168 merging. The attacker can now insert a packet with the PW label 169 associated with any PW (as inner labels are not inspected by provider 170 routers). By judicious choice of sequence number, the attacker may 171 be able to force massive packet loss, as mentioned above. 173 4. Defensive Techniques 175 4.1. PW Packet Authentication 177 One way of ensuring that a packet is a valid PW packet, is to 178 authenticate it by inserting a cryptographically derived field 179 between the control word and the payload. It is envisaged that the 180 insertion of such a field will be agreed upon between the two PEs 181 using an extension to the PWE control protocol. This method will 182 only be useful when the desired PW packets emanate from a PE with 183 this capability, and when there is a secure key distribution 184 infrastructure. 186 In a light-weight version that may be sufficient for some 187 applications, and which could be implemented entirely in software, a 188 32-bit cookie is inserted that is derived entirely from the control 189 word, or (for SS-PWs), from the control word and PW label. The 190 mapping of control word to cookie may make use of symmetric or 191 public-key methods. 193 In a more heavy-weight version a 64-bit authentication cookie is 194 inserted which results from a cryptographic hash on the entire PW 195 payload. The authentication of this cookie should be hardware- 196 assisted in order to avoid a denial of service attack based on 197 sending invalid packets in order to overload computational resources. 199 4.2. PW Packet Encryption 201 In order to secure PW traffic from unauthorized observation we may 202 encrypt it 203 below the PW level (link encryption), or 204 at the PW level, or 205 above the PW level (service encryption). 207 Link encryption and service encryption are well understood, but PW 208 level encryption requires a new mechanism. The first question is 209 what is encrypted at this layer. Since the PW label is part of the 210 MPLS label stack, encrypting it would render the packet illegal from 211 an MPLS point of view. The first nibble of the control word enables 212 packet classification for ECMP, and thus encrypting it would disrupt 213 ECMP mechanisms [6]. 215 On the other hand, if only the payload is encrypted, PW level 216 encryption becomes similar to service encryption. A universal 217 mechanism for securing PW packets of all types in proposed in [8] The 218 main difference relates to the use of the sequence number. PW 219 mechanisms do not provide packet reliability, thus encryption must 220 function on a packet-by-packet basis, and recover from occasional 221 lost packets. Hence service level encryptions based on stream 222 ciphers may not directly applicable. PW layer encryption may rely on 223 the sequence number (when the control word is used) but not directly 224 on the data stream, or even the number of bytes that have been 225 transmitted. 227 5. Security Considerations 229 Since this entire document is about security considerations, a 230 security consideration section would be superfluous. 232 6. IANA Considerations 234 This Internet Draft does not propose a protocol, nor change any 235 existing protocol, and thus no IANA considerations are raised. 237 7. Informative References 239 [1] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label 240 Switching Architecture", RFC 3031, January 2001. 242 [2] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. 243 Thomas, "LDP Specification", RFC 3036, January 2001. 245 [3] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge 246 (PWE3) Architecture", RFC 3985, March 2005. 248 [4] Fang, L., "Security Framework for Provider-Provisioned Virtual 249 Private Networks (PPVPNs)", RFC 4111, July 2005. 251 [5] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, 252 "Pseudowire Setup and Maintenance Using the Label Distribution 253 Protocol (LDP)", RFC 4447, April 2006. 255 [6] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal Cost 256 Multipath Treatment in MPLS Networks", 257 draft-ietf-mpls-ecmp-bcp-03.txt (work in progress), August 2007. 259 [7] Fang, L., Behringer, M., Callon, R., Le Roux, JL., Zhang, R., 260 and P. Knight, "Security Framework for MPLS and GMPLS Networks", 261 draft-fang-mpls-gmpls-security-framework-00.txt (work in 262 progress), August 2007. 264 [8] Stein, Y(J)S., "Pseudowire Security (PWsec)", 265 draft-draft-stein-pwe3-pwsec-00.txt (work in progress), 266 October 2006. 268 Author's Address 270 Yaakov (J) Stein 271 RAD Data Communications 272 24 Raoul Wallenberg St., Bldg C 273 Tel Aviv 69719 274 ISRAEL 276 Phone: +972 3 645-5389 277 Email: yaakov_s@rad.com 279 Full Copyright Statement 281 Copyright (C) The IETF Trust (2007). 283 This document is subject to the rights, licenses and restrictions 284 contained in BCP 78, and except as set forth therein, the authors 285 retain all their rights. 287 This document and the information contained herein are provided on an 288 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 289 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 290 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 291 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 292 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 293 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 295 Intellectual Property 297 The IETF takes no position regarding the validity or scope of any 298 Intellectual Property Rights or other rights that might be claimed to 299 pertain to the implementation or use of the technology described in 300 this document or the extent to which any license under such rights 301 might or might not be available; nor does it represent that it has 302 made any independent effort to identify any such rights. Information 303 on the procedures with respect to rights in RFC documents can be 304 found in BCP 78 and BCP 79. 306 Copies of IPR disclosures made to the IETF Secretariat and any 307 assurances of licenses to be made available, or the result of an 308 attempt made to obtain a general license or permission for the use of 309 such proprietary rights by implementers or users of this 310 specification can be obtained from the IETF on-line IPR repository at 311 http://www.ietf.org/ipr. 313 The IETF invites any interested party to bring to its attention any 314 copyrights, patents or patent applications, or other proprietary 315 rights that may cover technology that may be required to implement 316 this standard. Please address the information to the IETF at 317 ietf-ipr@ietf.org. 319 Acknowledgment 321 Funding for the RFC Editor function is provided by the IETF 322 Administrative Support Activity (IASA).