idnits 2.17.1 draft-deng-ipsec-gre-key-ts-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 212. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 218. 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 (June 13, 2008) is 5796 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4301' is defined on line 144, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Deng 3 Internet-Draft China Mobile 4 Intended status: Standards Track Y. Ma 5 Expires: December 15, 2008 Hitachi 6 Y. Wu 7 ZTE USA 8 June 13, 2008 10 GRE key as the traffic selector for IPsec tunnel 11 draft-deng-ipsec-gre-key-ts-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 15, 2008. 38 Abstract 40 This document describes the IPsec Tunnel based on GRE key as the 41 traffic selector. When GRE key is used in IP packet transmission 42 scenario of the wireless communication. Several enterprise need 43 different security policy when transmit the packet through some 44 unguaranteeded Internet cloudy. This document propose to adopt GRE 45 key as the IPsec traffic selector. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Network Scenario . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. GRE key as IPsec traffic selector . . . . . . . . . . . . . . 6 52 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 53 5. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 8 54 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 55 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 57 Intellectual Property and Copyright Statements . . . . . . . . . . 12 59 1. Introduction 61 GRE key has been used to allocate to encapsulate the traffic between 62 two IP access gateways in many ways including the 3GPP [TS23.402]. 64 Some company have some branch office would like to access from 65 wireless Internet communication technologies, and coincidently some 66 operator's mobile Internet is mixed together with public Internet, in 67 such scenario, they may need different security policy for each 68 connections. 70 In such scenarios, GRE key as the IPsec traffic selector is proposed. 72 2. Network Scenario 74 In some wireless communication, some IP mobilty management protocol 75 has mandate the IPsec tunnel between different mobility agents. 77 Private addressing is common for user address allocation by 78 operators. As shown in Fig. 1, if users from different enterprise 79 headquarter (A and B) roaming to the same visited network and the 80 same private address is allocated to users, the access router need to 81 differentiate data from the users. In this case GRE key will be used 82 to identify the tunnel from different users. 84 IPsec can be used to protect the GRE encapsulated packets. Operator 85 can have its own security policy on whether to secure the data for 86 users of different operators. For example, if user is from 87 enterprise A, the data will be protected by some security policy. If 88 the user is from enterprise B, the data will be protected 89 differently. 91 In such case, it is impossible to differentiate packets from 92 different users by using current traffic selector defined in IPsec. 93 GRE key is necessary to be a traffic selector for Operator to deploy 94 the security policy. 96 +------------+ 97 |Enterprise-A| 98 | | 99 | 10.x.0.0/16| 100 +------------+ 101 / 102 +------+ +------+ / 103 | | IPsec Tunnel | | / 104 MN-1---| |===================================| | / Key-1 105 | M |-----Flows with GRE Key-1 ---------| L | / Traffic 106 MN-2---| A |===================================| M |- 107 | G |===================================| A | \ Key-2 108 MN-3---| |-----Flows with GRE Key-2 ---------| | \Traffic 109 | |===================================| | \ 110 MN-4---| |-----Flows with GRE Key-3 ---------| | \ 111 +------+ +------+ \ 112 \ 113 Operator: Access Network +------------+ 114 |Enterprise-B| 115 | | 116 | 10.x.0.0/16| 117 +------------+ 119 Figure 1: Network scenario for GRE key based IPsec Tunnel 121 3. GRE key as IPsec traffic selector 123 Current IKE/IPsec implementation does not support GRE key as the 124 traffic selector. Extensions for IKE/IPsec is needed to support GRE 125 key. 127 4. Security Considerations 129 IPsec tunnel has been used for protecting data transmission between 130 two mobility agents. 132 5. IANA Consideration 134 This document defines no encodings, hence there are no IANA 135 considerations. 137 6. Conclusion 139 This document describes a GRE key as traffic selector based IPsec 140 tunnel mechanism. 142 7. Normative References 144 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 145 Internet Protocol", RFC 4301, December 2005. 147 [TS23.402] 148 3GPP, "TS 23.402: Architecture enhancements for non-3GPP 149 accesses", March 2008, 150 . 152 Authors' Addresses 154 Hui Deng 155 China Mobile 156 53A,Xibianmennei Ave., 157 Xuanwu District, 158 Beijing 100053 159 China 161 Email: denghui02@gmail.com 163 Yuanchen Ma 164 Hitachi 165 2, Kexueyuan Nanlu 166 Haidian District, 167 Beijing 100053 168 China 170 Email: ycma610103@gmail.com 172 Yingzhe Wu 173 ZTE USA 174 10105 Pacific Heights Blvd, Suite 250 175 San Diego, CA 92121 176 USA 178 Email: yingzhe.wu@zteusa.com 180 Full Copyright Statement 182 Copyright (C) The IETF Trust (2008). 184 This document is subject to the rights, licenses and restrictions 185 contained in BCP 78, and except as set forth therein, the authors 186 retain all their rights. 188 This document and the information contained herein are provided on an 189 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 190 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 191 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 192 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 193 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 194 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 196 Intellectual Property 198 The IETF takes no position regarding the validity or scope of any 199 Intellectual Property Rights or other rights that might be claimed to 200 pertain to the implementation or use of the technology described in 201 this document or the extent to which any license under such rights 202 might or might not be available; nor does it represent that it has 203 made any independent effort to identify any such rights. Information 204 on the procedures with respect to rights in RFC documents can be 205 found in BCP 78 and BCP 79. 207 Copies of IPR disclosures made to the IETF Secretariat and any 208 assurances of licenses to be made available, or the result of an 209 attempt made to obtain a general license or permission for the use of 210 such proprietary rights by implementers or users of this 211 specification can be obtained from the IETF on-line IPR repository at 212 http://www.ietf.org/ipr. 214 The IETF invites any interested party to bring to its attention any 215 copyrights, patents or patent applications, or other proprietary 216 rights that may cover technology that may be required to implement 217 this standard. Please address the information to the IETF at 218 ietf-ipr@ietf.org.