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

[Stephen Farrell <[e-mail]>]

On 28/08/14 05:42, Charlie Perkins wrote:
> 
> Hello folks,
> 
> I am basically O.K. with the suggested. 

Same here. Thanks.

> A couple of minor points:
> 
> - "any standard security negotiation protocols" -- should this be
> restricted to IETF
>     protocols?  What is the difference between a "security negotiation
> protocol"
>     and a "security protocol"?  Shouldn't we allow static configuration
> in some
>     circumstances for some installations?

Right. In a sense there's no need to say that at all. For interop
with pmipv6 that doesn't split the cp/up, you gotta use IPsec as
that's all the spec'd now. If that's not what concerns you as an
implementer (e.g. between your very own cp/up devices) then you're
as free as ever to do whatever. (Modulo customer RFQs etc.) So not
sure there's that much value in flexibility there.

Cheers,
S.

> 
> - "make the use of IPsec as optional"  -->  "does not require the use of
> IPsec"
>         or, maybe, "specifies that the use of IPsec is optional"
> 
> Is it the consensus of those involved here that this change does not
> require
> input from the working group?
> 
> Regards,
> Charlie P.
> 
> 
> 
> On 8/27/2014 6:03 PM, Sri Gundavelli (sgundave) wrote:
>> Hi Stephen,
>>
>> Please see the below text on security considerations for CP and UP
>> traffic protection. On thinking about this further, I have a feeling
>> we are adding a additional requirement here on User-Plane node on
>> IPsec implementation.
>>
>> The base line text in RFC 5213 requires IPSec as mandatory-to-implment
>> mechanism. However, it does not require the same for user -plane
>> traffic protection. But, one can argue that IPSec was implemented for
>> CP traffic protection and therefore implementation on that UP (UP-CP
>> combo) node already existed. I cannot beat that argument, but that was
>> not surely the original intent in RFC5213. Any ways, I'm fine having
>> IPsec as a mandatory-to-implement on both CP and UP nodes. Please see
>> the below text.
>>
>>
>>
>> NEW:
>>
>> *The Proxy Mobile IPv6 specification [RFC5213] requires the signaling
>> messages between the MAG and the LMA to be protected using end-to-end
>> security association(s) offering integrity and data origin
>> authentication. The base specification also requires IPsec a
>> mandatory-to-implement security mechanism. *
>> *
>> *
>> *In deployments where the Control and User Plane functions on the MAG
>> and LMA are separated and hosted on different IP nodes, the nodes
>> hosting those respective Control Plane functions have to still meet
>> the above the security requirement. The Proxy Mobile IPv6 signaling
>> messages exchanged between these entities MUST be protected using
>> end-to-end security association(s) offering integrity and data origin
>> authentication. Furthermore, IPsec is a mandatory-to-implement
>> security mechanism for the nodes hosting the Control Plane function of
>> the MAG and LMA. Additional documents may specify alternative
>> mechanisms and the mobility entities can enable a specific mechanism
>> for securing Proxy Mobile IPv6 signaling messages, based on either a
>> static configuration or after a dynamic negotiation using any standard
>> security negotiation protocols. *
>> *
>> *
>> *As per the Proxy Mobile IPv6 specification, the use of IPsec for
>> protecting the mobile node's user plane traffic is optional. This
>> specification extends the same requirement and therefore requires the
>> nodes hosting the User Plane functions of the MAG and the LMA to have
>> IPsec as a mandatory-to-implement security mechanism, but make the use
>> of IPsec as optional for User Plane traffic protection.*
>>
>>
>>
>> _Text in RFC5213:_
>>
>>
>> *   The signaling messages, Proxy Binding Update, and Proxy Binding*
>> *   Acknowledgement, exchanged between the mobile access gateway and the*
>> *   local mobility anchor, MUST be protected using end-to-end security*
>> *   association(s) offering integrity and data origin authentication.*
>> *
>> *
>> *   The mobile access gateway and the local mobility anchor MUST*
>> *   implement IPsec for protecting the Proxy Mobile IPv6 signaling*
>> *   messages [RFC4301].  IPsec is a mandatory-to-implement security*
>> *   mechanism.  However, additional documents may specify alternative*
>> *   mechanisms and the mobility entities can enable a specific mechanism*
>> *   for securing Proxy Mobile IPv6 signaling messages, based on either a*
>> *   static configuration or after a dynamic negotiation using any*
>> *   standard security negotiation protocols.  As in Mobile IPv6*
>> *   [RFC3775], the use of IPsec for protecting a mobile node's data*
>> *   traffic is optional.*
>>
>>
>> Regards
>> Sri
>>
>>
>>
>>
>> On 8/22/14 4:10 PM, "Stephen Farrell" <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>
>>
>>     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]><mailto:[e-mail]>
>>         <mailto:[e-mail]%3E>> 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]><mailto:[e-mail]>
>>
>>        
>> <mailto:[e-mail]%3E%3Cmailto:[e-mail]%3E>>
>>
>>         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]><mailto:[e-mail]>
>>
>>        
>> <mailto:[e-mail]%3E%3Cmailto:[e-mail]%3E>>
>>
>>         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
>>         <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>
>>
>>        
>> <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-06#ref-OpenFlow-Spec-v1.4.0%3E>],
>>
>>         FORCES [RFC5810 <http://tools.ietf.org/html/rfc5810>
>>         <http://tools.ietf.org/html/rfc5810%3E>], 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>
>>
>>        
>> <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-06#ref-I-D.matsushima-stateless-uplane-vepc%3E>]
>>
>>         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>
>>
>>        
>> <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-06#ref-OpenFlow-Spec-v1.4.0%3E>],
>>
>>         FORCES [RFC5810 <http://tools.ietf.org/html/rfc5810>
>>         <http://tools.ietf.org/html/rfc5810%3E>], 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>
>>
>>        
>> <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-06#ref-I-D.matsushima-stateless-uplane-vepc%3E>]
>>
>>         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]><mailto:[e-mail]
>>         <mailto:[e-mail]%3E%3Cmailto:[e-mail]>>
>>         https://www.ietf.org/mailman/listinfo/netext
>>
>>
>>
>>
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
> 
>