Subject: Re: [Apn] APN presentation in SAAG on Thursday.

From: David Schinazi <[email-masked]>
Date: Fri, 12 Mar 2021 10:44:19 -0800

Hello Zhenbin and Shuping,

Thank you for the discussion in SAAG. Now that I have a better
understanding of your proposal, I would like to share some thoughts here
on the list.

But first let's make sure I understood you correctly. In the meeting you
mentioned that the client device (e.g. mobile phone) does not send any
APN-related data, and that there is a network device that looks at the
5-tuple, and uses a classification mechanism to infer the APN data
(application ID, user ID, etc.). In theory, any network appliance that
wishes to provide applications with different treatment could run the same
classifier. You made the argument that this classifier might be expensive
to run on every network appliance, so you would prefer to run it once, and
write the result in the packet so other network appliances can simply use
the result. You also mentioned that there is a non-IETF encapsulation
mechanism being used between these network appliances. Is my understanding
correct? If not, can you point out anything I misunderstood?

Assuming I understood correctly, then I don't see a need for IETF to solve
this problem. You are free to modify the non-IETF encapsulation protocol to
augment it with this APN information, you do not need to have this
information in an IPv6 extension header, and you do not need an IETF
standard.

Therefore, I believe this work should not proceed at the IETF.

Regards,
David

On Wed, 10 March 2021 14:47 UTC, "Pengshuping (Peng Shuping)" <
[email-masked]> wrote:
> Hi Folks,
>
> Thanks to the ADs and the Chairs, we are going to present APN
(Application-aware Networking) in the SAAG working group at 13:00-15:00
(UTC+1) Thursday.
>
> APN is focused on developing a framework and set of mechanisms to derive,
convey and use an attribute information to allow for the implementation of
fine-grain user (group)-, application (group)-, and service-level
requirements at the network layer. APN works within a limited trusted
domain, which typically is defined as a service provider's limited domain
in which MPLS, VXLAN, SR/SRv6 and other tunnel technologies are adopted to
provide services.
>
> In the presentation, we would like to introduce the concepts, clarify the
scope, attract people to understand and discuss the topic, and collect
feedback and suggestions on this work, to further address the main concerns
that were raised by the IESG.
>
> For the SECers, we would like to especially know about what the security
issues are when the APN attribute is used within a limited operator's
controlled domain.
>
> Please find the latest version of the key draft, clarifying the scope and
the gap analysis.
> https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis-01
>
> We have been discussing in the APN mailing list regarding the various
aspects of APN. If you have not subscribed, you are very welcome to
subscribe. You can also find the archived discussions.
> https://datatracker.ietf.org/wg/apn/about/
>
> More information about APN can be found here.
> https://github.com/APN-Community
>
> Best Regards,
> Shuping

---

From: Lizhenbin <[email-masked]>
Date: Mon, 15 Mar 2021 08:49:37 +0000

Hi David,
Please refer to my reply inline.

Best Regards,
Robin

From: Apn [mailto:[email-masked]] On Behalf Of David Schinazi
Sent: Saturday, March 13, 2021 2:44 AM
To: Lizhenbin <[email-masked]>; Pengshuping (Peng Shuping) <[email-masked]>; APN <[email-masked]>
Subject: Re: [Apn] APN presentation in SAAG on Thursday.

Thank you for the discussion in SAAG. Now that I have a better understanding of your proposal, I would like to share some thoughts here on the list.

But first let's make sure I understood you correctly. In the meeting you mentioned that the client device (e.g. mobile phone) does not send any APN-related data, and that there is a network device that looks at the 5-tuple, and uses a classification mechanism to infer the APN data (application ID, user ID, etc.). In theory, any network appliance that wishes to provide applications with different treatment could run the same classifier. You made the argument that this classifier might be expensive to run on every network appliance, so you would prefer to run it once, and write the result in the packet so other network appliances can simply use the result. You also mentioned that there is a non-IETF encapsulation mechanism being used between these network appliances. Is my understanding correct? If not, can you point out anything I misunderstood?
[Robin]
1. It is right to run it once with the classification mechanism and the result can be carried in the limited network domain.
2. Because of the time reason, I did not explain more about the tunnel encapsulation in the SAAG session. Here I can explain more about the tunnel. Firstly, the GTP-u tunnel is standardized in 3GPP and also complied with the IETF standards on TCP/IP. Secondly the tunneled packet will go on to traverse the mobile transport network which will adopt the MPLS, SR and other tunnel encapsulation (that is the tunneled packet will be tunneled again). In addition, now there also exists work to use SRv6 tunnel as the alternative of GTU-u tunnel in IETF DMM WG. Finally, according to your example, I only explained the principle of wireless access. In fact in the fixed access and other enterprise network scenario, there will the use cases that packet will be directly tunneled through MPLS/SR/VXLAN without GTP-u.

Assuming I understood correctly, then I don't see a need for IETF to solve this problem. You are free to modify the non-IETF encapsulation protocol to augment it with this APN information, you do not need to have this information in an IPv6 extension header, and you do not need an IETF standard.
[Robin] As the above explanation and our clarification in the slide, the APN attribute info need be carried along with the MPLS/VXLAN/SR tunnels which are standardized in IETF (that is they are the IETF encapsulation). When SR is used, there is the SR over IPv6 (refer to the latest RFC8976). Thus for the SRv6 tunnel, the APN attribute info need to be encapsulated in the IPv6 extension header.

Therefore, I believe this work should not proceed at the IETF.
[Robin] If you think the APN attribute info can be carried along with the MPLS/SR/VXLAN tunnel, we need to proceed the work in the RTG area of IETF since most of the tunnels are standardized in the area. That is also the reason why I as the person always work in the RTG area presented the work in the sessions of the ART/SEC/INT areas. I wish the cross-area communication in the IETF can be help understand each other more.

Regards,
David

On Wed, 10 March 2021 14:47 UTC, "Pengshuping (Peng Shuping)" <[email-masked]<mailto:[email-masked]>> wrote:
> Hi Folks,
>
> Thanks to the ADs and the Chairs, we are going to present APN (Application-aware Networking) in the SAAG working group at 13:00-15:00 (UTC+1) Thursday.
>
> APN is focused on developing a framework and set of mechanisms to derive, convey and use an attribute information to allow for the implementation of fine-grain user (group)-, application (group)-, and service-level requirements at the network layer. APN works within a limited trusted domain, which typically is defined as a service provider's limited domain in which MPLS, VXLAN, SR/SRv6 and other tunnel technologies are adopted to provide services.
>
> In the presentation, we would like to introduce the concepts, clarify the scope, attract people to understand and discuss the topic, and collect feedback and suggestions on this work, to further address the main concerns that were raised by the IESG.
>
> For the SECers, we would like to especially know about what the security issues are when the APN attribute is used within a limited operator's controlled domain.
>
> Please find the latest version of the key draft, clarifying the scope and the gap analysis.
> We have been discussing in the APN mailing list regarding the various aspects of APN. If you have not subscribed, you are very welcome to subscribe. You can also find the archived discussions.