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

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

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.

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


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

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

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

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. 

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


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