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

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 07 Aug 2014 05:50:31 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-netext-pmip-cp-up-separation-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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. 

(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?

(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.

----------------------------------------------------------------------
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.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 9 Aug 2014 16:54:34 +0000

Hi Stephen,

Thanks for the review. Please see inline.

>ever knew about PMIPv6 and gotten stuff wrong here.

Not at all. Thanks for the discussion.

>presumably continue on the control plane but what else changes?

Yes. PMIPv6 allows the use of IPsec security (Tunnel Mode ESP) protection
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), the MAG (or MAG-DP) and the
LMA-DP can optionally enable IPsec security on the user-plane traffic.
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.

>end up going down the user plane.

The IP address of the mobile node is topologically anchored on the LMA-DP.
>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.

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.

The tunneled traffic with L3 encapsulation is between MAG-DP and LMA-DP.

Regards
Sri

>
>_______________________________________________
>netext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netext

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Aug 2014 13:21:14 +0100

Hiya,

A few follow ups...

> 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.)

> 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?)

> the MAG (or MAG-DP) and the

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?

> 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.

> The IP address of the mobile node is topologically anchored on the LMA-DP.

You mean LMA-UP there right?

> 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?

> 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?

Ta,
S.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Wed, 13 Aug 2014 16:45:18 +0000

HI Stephen,

Please see inline.

On 8/13/14 5:21 AM, "Stephen Farrell" <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[email-masked]>> wrote:

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.

Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should be the LMA-UP (User Plane)

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.

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.

Yes. Sorry for the terminology mix-up.

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.

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.

_______________________________________________
netext mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netext

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Aug 2014 23:51:44 +0100

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"
> <[email-masked]<mailto:[email-masked]>> 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"
> <[email-masked]<mailto:[email-masked]>> 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?)
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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:
> 
> 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>],
>
> [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:
> 
> 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 
> 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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 22 Aug 2014 23:08:35 +0000

Hi Stephen,

Thanks for the review.

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.

Regards
Sri

On 8/22/14 3:51 PM, "Stephen Farrell" <[email-masked]<mailto:[email-masked]>> wrote:

Hiya,

<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:

Ah.

Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should
be the LMA-UP (User Plane)

Cheers,
S.

COMMENT:

The identification of any of these CP messages is the use of the
following selector.
[email-masked]<mailto:[email-masked]><mailto:[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 23 Aug 2014 00:10:28 +0100

> We will draft some text to reflect this and post it for your review.

Great thanks,
S.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 28 Aug 2014 01:03:56 +0000

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" <[email-masked]<mailto:[email-masked]>> wrote:

Great thanks,
S.

Regards
Sri
On 8/22/14 3:51 PM, "Stephen Farrell" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]>> wrote:
Hiya,
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>> wrote:
<[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>> wrote:
[email-masked]<mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Aug 2014 10:00:52 +0100

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
>> 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" <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>         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.
>>         On 8/22/14 3:51 PM, "Stephen Farrell"
>>         <[email-masked]
>>        
>> <mailto:[email-masked]><mailto:[email-masked]>
>>         <mailto:[email-masked]%3E>> wrote:
>>         Hiya,
>>         <[email-masked]
>>        
>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>
>>
>>        
>> <mailto:[email-masked]%3E%3Cmailto:[email-masked]%3E>>
>>
>>         wrote:
>>         Hiya,
>>         A few follow ups...
>>         <[email-masked]
>>        
>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]>
>>
>>        
>> <mailto:[email-masked]%3E%3Cmailto:[email-masked]%3E>>
>>
>>         wrote:
>>         mean
>>         I don't
>>         for the
>>             From the point of view of Routing, the LMA-DP owns that
>>             larger IP
>>
>>         prefix
>>         <http://tools.ietf.org/html/rfc5844#page-15>
>> <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
>> <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>]
>>
>> <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
>> <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>]
>>
>>         sent in
>> <mailto:[email-masked]><mailto:[email-masked]><mailto:[email-masked]
>>         <mailto:[email-masked]%3E%3Cmailto:[email-masked]>>

---

From: Brian Haberman <[email-masked]>
Date: Thu, 28 Aug 2014 08:02:52 -0400

Hi Charlie,

On 8/28/14 12:42 AM, Charlie Perkins wrote:
> 
> Hello folks,
> 
> I am basically O.K. with the suggested.  A couple of minor points:
> 

Not at all, that is why the WG mailing list is copied on these
discussions.  As the shepherding AD, I want to make sure that the
discussion with the dissenting AD is resolved.  If WG members disagree
with the proposed changes, they are free to raise that disagreement.  If
the resulting changes are substantive, I will ask the chairs to review
those changes with the WG prior to any publication approval.

Regards,
Brian

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 28 Aug 2014 14:32:10 +0000

Thanks Stephen. We will go with that text then.

On 8/28/14 5:02 AM, "Brian Haberman" <[email-masked]> wrote:

> If WG members disagree

The proposed text on IPsec is inline with the base spec. We kept the
following original agreements.

1.) Protection for PMIPv6 signaling messages with end-to-end security
association(s) offering integrity and data origin authentication.
2.) IPsec is a mandatory to implement on CP nodes
3.) IPsec is mandatory to implement on UP nodes
4.) Use of IPsec for user plane traffic protection is optional
5.) New specifications can be define alternative security mechanisms for
protecting signaling messages

This is inline with the text in RFC-5213. My comment was on #3, where the
implementation of IPsec was mandated indirectly by having a requirement
for CP traffic protection. Nothing substantial. Explicit statements on the
protocol security for the split CP/DP architecture.

Working Group:

Any comments on the below text, please speak up.

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.

Regards

Sri