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

["Sri Gundavelli (sgundave)" <[e-mail]>]

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.



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