Re: New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

Uma Chunduri <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <CAF18ct4dZ9intbyz3zGTsvEwE=8+cYaw4WPhBFd1DYN2QdwTHQ@mail.gmail.com>
Hi Kausik,

Many thanks for your clarification below.

in-line..

--
Uma C.

On Mon, Oct 26, 2020 at 12:48 PM Majumdar, Kausik <
[email protected]> wrote:

> Hi Uma,
>
>
>
> My comments are inline below.
>
>
>
> *From:* dmm <[email protected]> *On Behalf Of * Uma Chunduri
> *Sent:* Wednesday, October 21, 2020 6:18 PM
> *To:* dmm <[email protected]>
> *Subject:* Re: [DMM] New Version Notification for
> draft-clt-dmm-tn-aware-mobility-07.txt
>
>
>
>

>
>
We already described the generic case where security is applied (section
> 2.6), when the user plane emits the packet to transport (could be N3/N9
> interfaces or S1U interface terminating at SGWs).
>
That addresses mostly shared transport cases.
>
If I understand correctly, you want security done by PE's before gNB/UPF??
> I can imagine few usef of this but can you explain why you are looking for
> this option?
>

>
Yes, I am looking for UE traffic to be secured by the PE’s before gNB/UPF.
> There could be specific traffic types for MIOT, EMBB, and URLLC service
> types where security is more important. Even this draft is addressing data
> path security for these service types the security characteristics needs to
> be preserved all the to the traffic destination, it can’t stop at SGWs or
> UPF. Then, the purpose for UE traffic to achieve end to end security is
> lost.
>


Ack. The case currently being handled is only for shared transport
perspective and security for all the traffic and not per particular set of
traffic.



> Specially if we look into SD-WAN deployments the security is the key
> aspects and the SD-WAN Edge Nodes establish secure IPSec tunnels between
> them. Here
> https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-08 nicely
> captures SD-WAN use cases for Homogeneous and Hybrid networks. Considering
> that, if the UE traffic needs to go beyond SGWs/UPF to the actual
> destination in the Data Network connected through SD-WAN Edge Nodes
> (Enterprise 5G case) the security characteristics for all the SSTs need to
> be preserved to maintain the E2E security.
>

>
I see while this can be done from UE side E2E, you are seeking a network
solution with SST granularity, not only beyond UPF in the DN but also in
the mobility domain.

I think it would be good to expand the UDP Src Port range table captured in
> Figure 2. For all of the current SST types we could come up with different
> Range where E2E security is the key requirement for the UE traffic like
> below:
>

>
UDP Src Port Range Ax – Ay : SST - MIOT with Security
>
..
>

> So you may need this for all SSTs then. Sure, we can enhance this part
(after consulting with other co-authors).



>
>
Sure. But is this a mandatory option for your E2E use case with
> SD-WAN beyond mobility domain?
>

>
I would say it is a mandatory option for E2E use cases with SD-WAN beyond
> mobility domain. If you look into the retail stores, education, etc (small
> to medium enterprise deployments), majority of the connections land into
> cloud with a secure tunnel connectivity to the cloud GW. These enterprise
> SD-WAN edge devices accept connections not only from wireless APs, but also
> for the mobility traffic through SWGs/UPF. In the case of UE mobility
> traffic needs to land into large enterprise with a security aspects, the
> SD-WAN GW in the corporate network need to preserve that behavior for E2E
> security.
>

>
Hope it clarifies.
>

Yes, it does. Thank you!

How the SD-WAN GW map the TN characteristics in non-mobility domain to
> maintain UE’s E2E traffic characteristics is being worked out, and would be
> submitted.
>
I have a few more questions and shall talk offline.



>
Regards,
>
Kausik
>

>

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.