Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT)
"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Wed, 13 August 2014 16:45 UTC
Return-Path: <sgundave@cisco.com>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649311A00F6; Wed, 13 Aug 2014 09:45:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.168
X-Spam-Level:
X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huUfT4Yw4YuH; Wed, 13 Aug 2014 09:45:21 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CCC1A00C6; Wed, 13 Aug 2014 09:45:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35275; q=dns/txt; s=iport; t=1407948321; x=1409157921; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=JN499lX/15kIdvjtzx871QjaoqUyaIiicFFlukRJfRc=; b=AFZdvtWNlGgJZI0TbQB6UEihAXqP38YdjdP81B/YmBHpRpfhpHEHgb8P eBVJTSpyed8UhU3nng//FHOyZvdSJPuFzUCysMBHOkw0z1jJIP5NazLXk woAg8X07WyCzXEXx+ShardYCyYwC0Jab/2yf3mUk077uqRcCV/jLjyv1F s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAFAGSV61OtJA2D/2dsb2JhbABEFoJHRlJXBIQSxzOBWQENhnFTAYEUFneEBAEBBAEBAWsLEgEIOAECBC4LFBECBAENBYhCDcZiF4wdgkZlBAYBhEwFhQMCgQoBiHqCE4QmhnaBV4oqghyGYYIWgUZsAQGBRg
X-IronPort-AV: E=Sophos; i="5.01,857,1400025600"; d="scan'208,217"; a="68963786"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 13 Aug 2014 16:45:19 +0000
Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7DGjJVM019258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 16:45:20 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 11:45:19 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Thread-Topic: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT)
Thread-Index: AQHPtxX3ZO0YXSnk60yjpGKdxZ8H5w==
Date: Wed, 13 Aug 2014 16:45:18 +0000
Message-ID: <D010C9E9.158B79%sgundave@cisco.com>
In-Reply-To: <53EB583A.5070901@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.32.246.213]
Content-Type: multipart/alternative; boundary="_000_D010C9E9158B79sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/n-qmvvrj6Afs71hJhRS6uoT93qA
Cc: "netext@ietf.org" <netext@ietf.org>, "netext-chairs@tools.ietf.org" <netext-chairs@tools.ietf.org>, "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" <draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org>
Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT)
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext/>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Aug 2014 16:45:26 -0000
HI Stephen, Please see inline. On 8/13/14 5:21 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> wrote: Hiya, A few follow ups... On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: Hi Stephen, Thanks for the review. Please see inline. On 8/7/14 5:50 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>> wrote: I have two questions. They could be easy or hard, I'm not sure:-) Apologies in advance if I've forgotten what little I ever knew about PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the discussion. (1) PMIPv6 traffic between MAG and LMA is generally assumed to be protected via IPsec, right? Assuming that's actually done, does figure 1 here indicate a weakening of security since it shows that IP encapsulation is used between MAG-UP and LMA-UP without any mention of IPsec. Is that downgrading security? I get that the binding messages are the most important and will presumably continue on the control plane but what else changes? Yes. PMIPv6 allows the use of IPsec security (Tunnel Mode ESP) protection "allows"? Do you happen to know if that's really used or not in practice? (That's not a DISCUSS point, but I do wonder.) Security for user-plane traffic protection is used in very few deployments. Taking the Service Provider Wi-Fi deployment as an example, there is 802.1x security on the air interface, and then there is typical end to end application security (even a Google search is HTTPS protected). Now requiring security on the user plane traffic between two points in the operator network (LMA and MAG) is some what redundant, IMO. Use of IPsec for UP traffic protection is optional per MIPv6/PMIPv6 specs. I'd say banking type applications/deployments requires such multi-layer security. for the user-plane traffic. This is optional and is based on standard IPsec security. It requires no special interaction between IPsec and the Proxy Mobile IPv6 entities. In the split mode (LMA ==> LMA-CP & LMA-DP), What's LMA-DP? That's not mentioned in the draft? I assume you mean what the draft calls LMA-UP? (I.e. DP = data plane being the same as UP = user plane?) Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should be the LMA-UP (User Plane) the MAG (or MAG-DP) and the LMA-DP can optionally enable IPsec security on the user-plane traffic. Hmm. So you're saying IPsec can be on for the control plane and off for the user plane independently? Is that a good plan? I guess it'd be a bad plan if it were the other way around? I'd say this is the approach in use for today's integrated LMA (LMA-UP + LMA-CP) based deployments. IPsec security is enabled for CP traffic by default, as it is mandated by PMIPv6 specs. However, the IPsec security for UP is a optional requirement and most deployments don't enable IPsec for UP traffic protection. MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these peers can be configured to apply IPsec security on the tunneled traffic. So, there is no loss of functionality here and the CP/DP split approach is not resulting in weakened security. Well, it might if IPsec is on for one and off for the other. Or, if say MAG-CP and MAG-UP are from different vendors, then I don't know how they signal to one another to turn on/off IPsec if what we want is for IPsec to be on for both or off for both. I'd look at IPsec as a security policy between two peers. Use of IPsec for CP messages between two CP nodes (Ex: MAP-CP and LMA-CP) should not have any bearing on the use/non-use of IPsec security between two UP nodes (Ex: MAG-UP and LMA-UP). The security policy on the two UP nodes strictly determine the use/non-use of IPsec for tunnel traffic protection. But, if the hint is that this policy should be controlled by the respective CP entity, I'd say yes, but that CP to UP interface is out of scope for this work. The controller/CP entity may have a provisioning interface to the UP nodes and that interface may dictate this aspect, but has not implication on this draft. (2) How does the rest of the Internet know to use the LMA-UP for the MN and not the LMA-CP? Sorry for being dense but I don't see how packets from a random Internet node for the MN end up going down the user plane. The IP address of the mobile node is topologically anchored on the LMA-DP. You mean LMA-UP there right? Yes. Sorry for the terminology mix-up. >From the point of view of Routing, the LMA-DP owns that larger IP prefix block from which it allocates to IP prefixes/address to individual mobility sessions. The LMA-DP is in the path for the user-plane traffic and is the entry point into the mobile network. However, the LMA-CP is only terminating the control signaling from the MAG and is not in the path for the user-plane traffic. Is that written down somewhere? If say the LMA-UP and LMA-CP had utterly different addresses then it couldn't work could it? This was captured in Section 5.6.2 for IPv6 http://tools.ietf.org/html/rfc5213#page-38 Section 3.1.3 for IPv4 http://tools.ietf.org/html/rfc5844#page-15 When we separate the functionality, the user plane (or the IP address/prefixes allocated to the MN) must be anchored on the LMA-UP. I think we missed capturing this in the spec. Thanks for pointing this out. OLD: The LMA Control Plane and the LMA User Plane functions are typically deployed on the same IP node and in such scenario the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA Control Plane and the LMA User Plane functions on seperate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions and which is outside the scope of this document. Possible options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-06#ref-OpenFlow-Spec-v1.4.0>], FORCES [RFC5810 <http://tools.ietf.org/html/rfc5810>], use of routing infrastructure [I-D.matsushima-stateless-uplane-vepc <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-06#ref-I-D.matsushima-stateless-uplane-vepc>] or vendor specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. NEW: The LMA Control Plane and the LMA User Plane functions are typically deployed on the same IP node and in such scenario the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA Control Plane and the LMA User Plane functions on seperate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions and which is outside the scope of this document. Possible options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-06#ref-OpenFlow-Spec-v1.4.0>], FORCES [RFC5810 <http://tools.ietf.org/html/rfc5810>], use of routing infrastructure [I-D.matsushima-stateless-uplane-vepc <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-06#ref-I-D.matsushima-stateless-uplane-vepc>] or vendor specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. When the LMA Control Plane and the LMA User Plane functions are deployed on separate IP nodes, the requirement related to user-plane address anchoring specified in Section 5.6.2 [RFC-5213] and Section 3.1.3 [RFC5844] must be met by the node hosting the LMA user plane functionality. The LMA user plane node must be topological anchor point for the IP address/prefixes allocated to the mobile node. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Did you need to say somewhere which PMIPv6 messages are to be sent in the control plane and which in the user plane? That might be obvious to some, but its not to me and I guess there are a bunch of PMIPv6 extensions so I could imagine that someone somewhere might get it wrong. The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port 5436) traffic is exchanged between MAG-CP and LMA-CP. There is no implication on the use/non-use of other mobility options. Sure. My question is: where is it written down which are signalling messages and which are not? PMIPv6 Signaling messages (aka control plane messages) are PBU/PBA, BRI/BRA and UPN/UPA messages. The formats for these messages are specified in RFC 5213, 5844, 5846, 5847, 7077. Ex: http://tools.ietf.org/html/rfc5213#page-69 http://tools.ietf.org/html/rfc6275#page-42 The identification of any of these CP messages is the use of the following selector. 1. Any IPv4-UDP packets with UDP port 5436 2. Any IPv6 packets with Mobility Header messages Existing specs clearly explain this and I think its sufficiently clear for the implementors on what traffic goes to LMA-CP and what goes to the LMA-UP. Regards Sri Ta, S. The tunneled traffic with L3 encapsulation is between MAG-DP and LMA-DP. Regards Sri _______________________________________________ netext mailing list netext@ietf.org<mailto:netext@ietf.org> https://www.ietf.org/mailman/listinfo/netext
- [netext] Stephen Farrell's Discuss on draft-ietf-… Stephen Farrell
- Re: [netext] Stephen Farrell's Discuss on draft-i… Sri Gundavelli (sgundave)
- Re: [netext] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [netext] Stephen Farrell's Discuss on draft-i… Sri Gundavelli (sgundave)
- Re: [netext] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [netext] Stephen Farrell's Discuss on draft-i… Sri Gundavelli (sgundave)
- Re: [netext] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [netext] Stephen Farrell's Discuss on draft-i… Sri Gundavelli (sgundave)
- Re: [netext] Stephen Farrell's Discuss on draft-i… Stephen Farrell
- Re: [netext] Stephen Farrell's Discuss on draft-i… Brian Haberman
- Re: [netext] Stephen Farrell's Discuss on draft-i… Sri Gundavelli (sgundave)