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

[<[e-mail]>]

Hi Kent,

Its been a while since you did the review. Finally getting back to
updating the I-D and responding to your comments:

>In the last IETF meeting, I signed up to review this draft and
>provide my comments to the WG.  Some may already be discussed.
>
>1)      Sect. 1: s/cellular accesses/cellular access networks/

Okay.

>2)      Sect. 1: "that would unnecessarily consume resources on the HA
>and radio resources on the access network"

Okay.

>3)      Sect. 1: HA control is mentioned in "Furthermore, the operator
>of HA may have policies .. security is to be used".  But later "HA has
>no ability to force the MN to secure user traffic".  Clarify if SoD is
>designed to include HA control in addition to MN control.

Correct. MIP6 signaling today is primarily MN initiated. As a result
it is straightforward for the MN to request the establishment of
security for the user plane as needed by sending a binding update
message to the HA. From the HA perspective, we only have the binding
revocation message today which can be sent to an MN. This is the only
unsolicited message that can be used by the HA to send a notification
to the MN.
SoD is indeed designed to allow user plane security to be initiated
either by the MN or the HA.

>4)      Sect. 2: s/wifi_SSID/WiFi SSID/

Okay.

>5)      Sect. 2: Why MAC_address of the wifi network?  Generally, it's
>the WIFI SSID.  Probably better to cover general logic and not get
>into specific features.

SSIDs can be spoofed quite easily. Of course so can MAC
addresses. However an HA/Policy store may maintain SSID->MAC address
mappings that help determining if the network to which an MN is
attached secure and this information can trigger security to be
enabled/disabled for the user plane traffic. That is the reason why
MAC address is included here.

>6)      Sect. 2: "MN has either a stored policy ~ or it may be
>provided with such information from policy stores such as ANDSF
>[23.402] or AAA server ~" There is no interface between MN and AAA
>server.  So not clear how MN is able to obtain info stored on AAA
>server.  Also, PCRF may be another policy store.

Right.. The MN does not have an interface with the AAA server. What we
intended to say is that these policies are delivered to the MN at the
time of access authentication. But its a good point and we need to
provide more details of how the AAA provides the policies to the MN.
One example of course is the use of ANDSF in 3GPP networks. The ANDSF
can deliver policies to the MN using OMA-DM.

>7)      Sect. 2: "HA may require that the user plane traffic be
>encrypted on the MN-HA link".  No description of how this can be
>accomplished.

We intend to reuse the binding revocation message with a different
semantic to enable this. Details about how this is done will be
included in the next rev of the I-D.

>8)      Sect. 3: 'S' bit indicates encryption for user traffic.  But
>it~s not clear how encryption can be applied?

First of all we are getting rid of the "S" bit and instead specifying
a mobility option that enables multiple capabilities w.r.t security
for the user plane traffic.
The mobility option will indicate whether traffic needs to be ciphered
or simply integrity protected. This is achieved by using the
applicable type of SA.

>9)      Sect. 3: What happens if MN does not encrypt after HA
>overwrites with S bit set to one?

The HA drops the traffic. It could also send an error message to the
MN.

>10)   Sect. 3: What happens if MN encrypt when HA does not want that?

Same as above (9).

>11)   Sect. 3: There is no description of HA triggered SoD, though HA
>control was implied in Sect. 1.

Right. Please see response to (3) above.

>12)   Sect 4.2: What  this option is in the draft?  Location
>information can be used for many types of operation, not specific to
>SoD

The location information can assist the policy store in the network in
determining of security for the user plane traffic is required. Hence
the option being included in the BU.

>13)   Sect. 5.: Hmm, Type value reservation needs IANA.

Yes.

>14)   Sect. 6: It~s not clear if there is no impact to the security
>model until further explanation provided on how the encryption is
>applied.

Encryption is applied by using an IPsec SA which is of type ESP
tunneled.

>
>Overall, the I-D is a good start on the idea of SoD.  It needs more
>clarification on how the S bit interact with the mechanism that
>actually provides the encryption/decryption function.  Also, how does
>SoD work when IKE/IPSec is providing the encryption/decryption.

Thanks for your comments. Further clarifications in the next rev
should address the shortcomings. Will appreciate your feedback once we
post the new rev.

-Raj

>
>Kent