Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

On 23/08/14 00:08, Sri Gundavelli (sgundave) wrote:
> Hi Stephen,
> 
> Thanks for the review.
> 
> 
>> In this case, you're not even requiring implementation.
> So if say, a MAG-UP were to talk to a LMA that is both
> CP and UP, then the latter node would support IPsec for
> UP, if so configured, but the MAG-UP might not even
> implement IPsec.
> 
>> Does that mean that you need to a a requirement here to
> make IPsec MTI for the MAG-UP and LMA-UP, so that they
> can interop with non-split MAGs and LMAs?
> 
> 
> Requiring IPsec implementation on both the MAG-UP and LMA-UP nodes is a fair requirement. We can certainly state that. If an operator chooses to do so they can configures IPSec policy on LMA-UP and MAG-UP for PMIP tunnel traffic protection. This will keep the spec consistent with the base RFC5213.
> 
> The signaling between LMA-CP and MAG-CP  needs to be protected by IPsec and that is a mandatory requirement in RFC5213. No change there. This specification still requires IPsec protection for control plane traffic between MAG-CP and LMA-CP.
> 
> We will draft some text to reflect this and post it for your review.

Great thanks,
S.


> 
> 
> 
> Regards
> Sri
> 
> 
> 
> On 8/22/14 3:51 PM, "Stephen Farrell" <[e-mail]<mailto:[e-mail]>> wrote:
> 
> 
> Hiya,
> 
> Sorry for the slow response...
> 
> The indentation below is a bit messed up, I hope its clear
> who's saying what.
> 
> On 13/08/14 17:45, Sri Gundavelli (sgundave) wrote:
> HI Stephen,
> Please see inline.
> On 8/13/14 5:21 AM, "Stephen Farrell"
> <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>> 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"
> <[e-mail]<mailto:[e-mail]><mailto:[e-mail]>> 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.
> 
> Ah.
> 
> 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.
> 
> Hmm. I don't see that it makes any sense to assume IPsec is
> done differently per-application. So I guess we ought assume
> that IPsec isn't used for user traffic.
> 
> Is it really used for control plane traffic do you know?
> 
> But in a sense this spec is lowering the bar a little.
> 5213 requires implementation of IPsec on the node that
> carries the UP traffic, even if it doesn't require its
> use.
> 
> In this case, you're not even requiring implementation.
> So if say, a MAG-UP were to talk to a LMA that is both
> CP and UP, then the latter node would support IPsec for
> UP, if so configured, but the MAG-UP might not even
> implement IPsec.
> 
> Does that mean that you need to a a requirement here to
> make IPsec MTI for the MAG-UP and LMA-UP, so that they
> can interop with non-split MAGs and LMAs?
> 
> I'd assume that'd be easy enough and it'd clear up
> that discuss point.
> 
> 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.
> 
> I'm not quite sure if that does sort out the issue or not,
> but I'm willing to believe you and Brian if you're telling
> me it does.
> 
> So with that OLD/NEW and adding IPsec as MTI for the
> *-UP nodes, I think we'd be done.
> 
> Cheers,
> S.
> 
> ----------------------------------------------------------------------
> 
> 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
> [e-mail]<mailto:[e-mail]><mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/netext
> 
>