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

From: jouni korhonen <[email-masked]>
Date: Wed, 9 Feb 2011 23:19:45 +0200

Hi,

In Beijing meeting I volunteered to review draft-bajko-mext-sod-01.

I'll skip the editorials and such. The text would need some editing for sure ;)

* Section 1

   As per the current MIP6 [RFC3775] specification, only the MN has the
   ability to enable security for user-plane traffic. The HA has no
   ability to force the MN to secure user traffic.

Strictly based on rfc3775 yes. However, if IKE is used as the key management protocol, then it is possible to have some level of security level negotiation between the MN and the HA. That approach would not be as dynamic as proposed in the I-D but still..

* Section 2

This section would definitely benefit from having more references to the different technologies/elements listed. Also expanding some of the acronyms would not make harm.

* Section 3

   response acknowledging the request and setting the flag for user
   plane traffic security to Null indicating to the MN that the traffic
   on the link between the MN and HA will not be encrypted.

Setting to "Null"..? Do you rather mean the HA modifies the SPD for HA->MN direction accordingly and makes the MN destined user traffic to bypass IPsec? And a similar action needs to be done on the MN for the MN->HA direction.

* Section 4.1

   S    When set, this flag indicates HA acknowledges, or strongly
   recommends, use of user plane encryption. When clear, HA does not
   support or allow use of user plane encryption.

This also means that the MN has no way of knowing whether the S was unset because a) HA policy said so, or b) HA did not understand the whole thing. In case of b) the MN might want to detach from this particular HA and try to find a HA that supports the feature proposed in this I-D. I see this as an issue that needs to be solved somehow. 

* Section 4.2

I understand the introduction of this option but would still consider it not being an essential part of the on-demand security enhancement proposed by this I-D.

* Section 5

   This document does not require actions by IANA.

I kind of disagree ;)

As a summary. The proposed solution seems useful. Some work on the I-D is though needed.

- Jouni

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 13:53:25 -0800

Jouni -

Thanks for the review!

Please see some comments below:

> Strictly based on rfc3775 yes. However, if IKE is used as the key management protocol, then it is possible to have some level of security level negotiation between the MN and the HA. That approach…

My understanding of IKE is that although it can be used to update the
SPD,  changing the fundamentals of a bypass or protect rules that
applies to user plane traffic wouldn't  fall in the scope of IKE --
see quote from RFC 5996:

   When an RFC4301-compliant IPsec subsystem receives an IP packet that
   matches a "protect" selector in its Security Policy Database (SPD),
   the subsystem protects that packet with IPsec.  When no SA exists
   yet, it is the task of IKE to create it.  Maintenance of a system's
   SPD is outside the scope of IKE, although some implementations might
   update their SPD in connection with the running of IKE (for an
   example scenario, see Section 1.1.3).

   Traffic Selector (TS) payloads allow endpoints to communicate some of
   the information from their SPD to their peers.  These must be
   communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY]
   uses the SADB_ACQUIRE message).  TS payloads specify the selection
   criteria for packets that will be forwarded over the newly set up SA.
   This can serve as a consistency check in some scenarios to assure
   that the SPDs are consistent.  In others, it guides the dynamic
   update of the SPD.

Would you disagree?

> Setting to "Null"..? Do you rather mean the HA modifies the SPD for HA->MN direction accordingly and makes the MN destined user traffic to bypass IPsec? And a similar action needs to be done on the…

I think so.

> This also means that the MN has no way of knowing whether the S was unset because a) HA policy said so, or b) HA did not understand the whole thing. In case of b) the MN might want to detach from t…

I agree with Jouni. And actually I've commented many times ;-) that
the flag should go away and a new mobility option should be included
that carries to flag, an 'I' for integrity protection, and a 'C' for
confidentiality protection since these are different capabilities.
Also having it in a mobility option would avoid the issue outline
since a HA that doesn' t understand the option would not send it back
and the MN wouldn't have to guess what happened.

> I understand the introduction of this option but would still consider it not being an essential part of the on-demand security enhancement proposed by this I-D.

Agree.

>   This document does not require actions by IANA.

I think we need action by IANA to register new mobility option.

> As a summary. The proposed solution seems useful. Some work on the I-D is though needed.

Agree.

--julien

---

From: <[email-masked]>
Date: Wed, 9 Feb 2011 21:55:32 +0000

Thanks for the reviews and comments.
We are cognizant of Julien's comments regarding the flag (from the past
two meetings :) ) and will make the necessary changes in the next rev.

-Raj

On 2/9/11 3:53 PM, "ext Julien Laganier" <[email-masked]> wrote:

>> Strictly based on rfc3775 yes. However, if IKE is used as the key
>>management protocol, then it is possible to have some level of security
>>level negotiation between the MN and the HA. That approach would not be
>>as dynamic as proposed in the I-D but still..
>
>> This section would definitely benefit from having more references to
>>the different technologies/elements listed. Also expanding some of the
>>acronyms would not make harm.
>>
>> * Section 3
>>
>> Setting to "Null"..? Do you rather mean the HA modifies the SPD for
>>HA->MN direction accordingly and makes the MN destined user traffic to
>>bypass IPsec? And a similar action needs to be done on the MN for the
>>MN->HA direction.
>
>I think so.
>
>> * Section 4.1
>>
>> This also means that the MN has no way of knowing whether the S was
>>unset because a) HA policy said so, or b) HA did not understand the
>>whole thing. In case of b) the MN might want to detach from this
>>particular HA and try to find a HA that supports the feature proposed in
>>this I-D. I see this as an issue that needs to be solved somehow.
>
>> I understand the introduction of this option but would still consider
>>it not being an essential part of the on-demand security enhancement
>>proposed by this I-D.
>
>Agree.
>
>> * Section 5
>>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 10 Feb 2011 00:22:54 +0200

Julien,

> applies to user plane traffic wouldn't  fall in the scope of IKE --

I should have written my thoughts clearer. What I meant here is that a MN and a HA may have a bunch of proposals to agree on. The MN and the HA can agree on a transform that provides no encryption. And this is essentially for the HA to enforce. I know it is somewhat far fetched but doable to some extent.

- JOuni

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 14:36:17 -0800

Jouni,

> I should have written my thoughts clearer. What I meant here is that a MN and a HA may have a bunch of proposals to agree on. The MN and the HA can agree on a transform that provides no encryption.…

Hmm. If for a single MN-HA pair there might be situations in which
confidentiality protection is to be afforded and other in which it is
not, the SPD will have to be modified. Quoting RFC 4301:

           o Processing info -- which action is required -- PROTECT,
             BYPASS, or DISCARD.  There is just one action that goes
             with all the selector sets, not a separate action for each
             set.  If the required processing is PROTECT, the entry
             contains the following information.
[...]
                - algorithms -- which ones to use for AH, which ones to
                  use for ESP, which ones to use for combined mode,
                  ordered by decreasing priority

Would it be correct to interpret your statement as having on the HA a
PROTECT rule with algorithms as follows and in that order:

    AES_CBC + HMAC-SHA1-96 followed by HMAC-SHA1-96

would allow the the MN to negotiate Confidentiality protection and
Integrity Protection vs. Integrity protection only by changing its
local SPD only to contain either AES_CBC + HMAC-SHA1-96
(Confidentiality protection and Integrity Protection) or HMAC-SHA1-96
(Intergrity protection only) and thus no MIPv6 signaling extension is
needed in this case because IKE would do the job?

I'd agree.

However, the SPD would have to be modified in case the userplane is to
be passed cleartext, and that means the HA SPD has to say BYPASS, and
IKE doen't allow to negotiate this.

Comments?

--julien

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 9 Feb 2011 16:43:53 -0600

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: (972) 910 3451  
Internal: 820.63451
: (510) 230 8422
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.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 10 Feb 2011 00:56:02 +0200

Hi again,

GOTO the end of mail.

> IKE doen't allow to negotiate this.

My original comment was to point out that the statement "The HA has no ability to force the MN to secure user traffic." is not so black and white in all cases. Using IKE definitely is not as slick as the solution proposed in the I-D. I am completely happy if the earlier statement is modified e.g. "The HA has limited abilities, if any, to force the MN to secure user traffic." And the probably referencing to RFC4877.

- JOuni

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 15:22:39 -0800

Hi Stefano,

Thanks for the review!

I am following up on your comments inline below:

> [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 –…

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?

> [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 c…

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.

> [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. 2…

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.

> [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,

>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 draf…

Hopefully I have clarified why I think this is useful.

--julien

---

From: "Stefano Faccin" <[email-masked]>
Date: Wed, 9 Feb 2011 17:41:33 -0600

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

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

Hi Stefano,

Thanks for the review!

--julien

---

From: Julien Laganier <[email-masked]>
Date: Wed, 9 Feb 2011 16:14:54 -0800

Stefano,

The last 3GPP TS 23.402 I've seen is at least incomplete. The
reference to 4877 and the statement that "the UE and the HA at any
time can request the establishment of a child SA" hold on as long as
the MN and HA are in sync regarding what protection to afford to user
plane which this draft provides a mean to.

--julien