Re: [MEXT] review of draft-bajko-mext-sod-01

["Stefano Faccin" <[e-mail]>]

Julien,
Thanks for the reply.

So, for my clarification, based on your first comment, what 3GPP has adopted for securing the user plane traffic for S2c (DSMIPv6) is incorrect, since it is based on RFC4877 and the fact that the UE and the HA at any time can request the establishment of a child SA?

I am not sure we want to reference something about ANDSF that has not been defined nor discussed yet. It would be pure speculation, especially considering 3GPP already has defined solutions for that. I would drop the reference to ANDSF altogether.

Stefano Faccin

Standards Manager
Research In Motion Corporation 
5000 Riverside Drive 
Building 6, Brazos East, Ste. 100
Irving, Texas 75039 USA 
Office: [phone]  
Internal: 820.63451
: [phone]
www.rim.com; www.blackberry.com 



 Consider the environment before printing.


-----Original Message-----
From: Julien Laganier [mailto:[e-mail]] 
Sent: Wednesday, February 09, 2011 3:23 PM
To: Stefano Faccin
Cc: [e-mail]
Subject: Re: [MEXT] review of draft-bajko-mext-sod-01

Hi Stefano,

Thanks for the review!

I am following up on your comments inline below:

On Wed, Feb 9, 2011 at 2:43 PM, Stefano Faccin <[e-mail]> wrote:
> Hello all,
> I finally got to review the draft as promised in Beijing. It seems Jouni and I completed the review at the same time. I have not yet read all the replies.
>
> === Section 1:
>
> "   As per the current specifications for MIP6 and DSMIP6, security of
>   the user plane traffic is optional. When the MN is attached to 3G/4G
>   network such as HSPA, LTE or EV-DO, the MN may not require security
>   for the user plane traffic since these networks already provide
>   ciphering over the air-interface and deploy hop-by-hop security,
>   which makes these networks secure. However the MN may attach to less
>   secure or unsecured accesses such as wireless lan (WLAN) or it may
>   roam in countries where the user may prefer the data between the MN
>   and the HA to be encrypted (even when using cellular accesses).
>   There is no solution in the protocol specification today which
>   provides the capability to trigger the security for the user plane
>   traffic on a need basis."
> [Stefano] when the MN attaches in one of the scenarios indicated (either the MN is connecting over access technology/network that it does not consider secure or it is connecting through a network – e.g. roaming cellular network – that it does not consider secure), the MN knows this fact (i.e. that it is not secure). Further down in the draft this is stated also by the authors. Then, since the MN knows of the lack of security at attachment, why can't the MN decide to establish the user plane security right away upon establishment of the connection? The text in the introduction seems to imply than in such cases the MN would wait and then a new mechanism is needed.

If the HA has an SPD entry for the user-plane traffic with action set
to PROTECT, the MN will not be able to send cleartext user-plane
packets when the access network it attached to is deemed secure and
thus no user-plane confidentiality protection would be needed.

Conversely, if the HA has an SPD entry for the user-plane traffic with
action set to BYPASS, the MN will not be able to send IPsec protected
user-plane packets when the access network it attached to is deemed
insecure and thus user-plane confidentiality protection would be
needed.

Does the above manages to shed some light on why is the mechanism needed?

> === Section 1
>
> "   The MIP6/DSMIP6 protocols only provide a means to secure the user
>   plane traffic but do not provide any mechanisms by which the
>   security is triggered as a result of mobility or the MN attaching
>   via different access networks."
>
> [Stefano] in my understanding, RFC4877 allows the MN to establish the security for the user plane traffic at any time (as the authors also state in section 2). What triggers the MN to do so is of course outside the scope of RFC4877, but it should be outside the scope of this draft also. If we don't consider what triggers the MN to establish the SA for the user plane, it seems to me that RF4877 is sufficient. Please note that as a example 3GPP has already adopted RFC4877 for securing the user plane on the S2c interface (DSMIPv6) where the MN or the HA at any time can establish a child SA for securing the user plane. That is to me clearly on-demand user plane security based on whatever criteria the MN and the HA implement to trigger the security establishment.

Although it is true establishment of IPsec SAs affording
confidentiality and/or integrity protection to user plane packets can
be initiated by the MN at any time, establishment of these SAs is
contingent to the IPsec SPD on both the MN and the HA specifying that
such protection be afforded to user plane traffic. Further, in the
presence of such SPD entries on the MN and HA, absence of the IPsec
SAs means not that traffic will be past clear text. On the contrary,
traffic will be buffered and/or discarded while the MN attempt to
establish the IPsec SAs required as per the SPD.

Conversely, in the absence of such SPD entries, the MN and HA will
never attempt establishment of IPsec SAs affording protection to user
plane packets. Further, if only the MN changes its SPD to require
protection but the HA hasn't (based on the signaling hereby proposed),
IKEv2 exchange will not lead to the HA accepting to establish such
SAs.

> === Section 2
>
> "   The MN has either a stored policy about trusted and untrusted access
>   networks or it may be provided with such information from policy
>   stores such as the ANDSF [23.402] or AAA server at the time of
>   network attachment."
>
> [Stefano] unfortunately I believe that quoting ANDSF as specified in 3GPP in 23.402 as the entity that may provide information to the MN on whether a network is trusted or untrusted is incorrect. 23.402 (and in particular the stage 3 in 24.302 and 24.312) do not contain such information that can be conveyed to the MN.

Agree that in its current form the ANDSF takes no position on whether
or not a network should be considered as trusted. This may change
however, so maybe rewording into "[...]  from extensions to policy
stores such as the ANDSF [23.402] or AAA server at the time of network
attachment." would ease your concern?

Another thing I'd like to see reference in this draft is the
possibility to use the presence or the absence of link layer
confidentiality protection as an input to the MN requesting
confidentiality protection. In wireless system, the first over-the-air
hop is the most vulnerable to eavesdropping.

> === Section 2
>
> "An interface exists generally between the policy
>   store such as AAA or ANDSF and the Home Agent (HA)."
>
> [Stefano] I need to disagree with this statement, as indicated in Beijing. There is no interface in 3GPP defined between the ANDSF and the HA, therefore the statement is incorrect.
>
> === Section 2
>
> "The MN or HA can  determine when to use security for the user plane
>   traffic using static policies or dynamic policies which can be
>   obtained at the time of network attachment; or e.g. which are
>   provisioned and maintained on a smartcard (eg, a UICC or SIM). 3GPP
>   policy stores such as the ANDSF can also provide information about
>   the access networks to which an MN is attached. Location of the MN
>   can also be used as input. "
>
> [Stefano] for sake of clarity, can we say "3GPP
>   policy stores such as the ANDSF can also provide to the MN information about
>   the access networks to which an MN is attached "
>
> === Section 3
>
> "   This document proposes extensions to MIPv6/DSMIPv6 protocol,
>   allowing the MN to signal to the HA its preference for user plane
>   traffic security
> "
>
> [Stefano] I am wondering why the MN needs to signal its preference. If the MN at any time wants to setup a child SA, why can’t the MN directly do it without indicating the preference?

Hopefully I have managed to answer that question with my earlier
comment on the need to have coordinated SPD on the MN and HA. Since
IKE doesn't allow modification to the SPD, this has to be coordinated
through MIPv6 signaling,


> === Section 3
>
> "  and for the HA to override that preference based
>   on the policy settings. "
> [Stefano] In the same way, if the MN at any time decides to establish an SA for the user plane, why can’t it do it based on RFC 4877, since the HA can accept it or deny the MN request anyway?
>
>
> In general, I have the same concern expressed in Beijing as to how the HA knows whether an access is trusted/untrusted and whether there is the need for user plane security, and therefore how the HA can decide to trigger the security establishment in a meaningful/educated way. Trusted/untrusted is not just a decision based on the available encryption over the radio interface, but also a roaming agreement. E.g. a given WLAN can be trusted for one operator but untrusted for another one, and it could even be trusted for one user (e.g. a user that anyway knows it needs to run VPN to connect to the desired services) but untrusted for another one. The HA cannot know such information. In the case of 3GPP networks, as it was discussed in Beijing, the trusted/untrusted decision is performed either by the MN (based on preconfigured information) or by the AAA infrastructure that authenticates the MN access to the specific access network. Please note that such authentication is separate for the DSMIPv6 authentication in 3GPP, and that the trusted/untrusted decision performed during the first authentication is not stored and "remembered" so that it can be provided to the HA. Again, this were the comments I raised in Beijing.

From my side, I believe the main usecase is one in which the MN
unilaterally decide whether to use encryption or not (based on L2
encryption being ON or OFF, and possibly whitelists pulled through
ANDSF or other policy store extensions, or user preferences) and
informs the HA about its choice so that the SPD are aligned on both
sides, thus resulting in IKEv2 establishing or not the required IPsec
SAs to afford protection to user plane packets.

> Overall, as I expressed in Beijing, I am not sure I see the need for this solution and its applicability to e.g. 3GPP, as indicated in the draft. Perhaps I need to be further educated, but the draft at present does not clarify why an additional solution is needed.

Hopefully I have clarified why I think this is useful.

--julien

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.