Re: [Apn] APN Policy Enforcement

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Tue, 14 December 2021 00:49 UTC

Return-Path: <pengshuping@huawei.com>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F5F3A0CE8 for <apn@ietfa.amsl.com>; Mon, 13 Dec 2021 16:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObUQK1_OLqwu for <apn@ietfa.amsl.com>; Mon, 13 Dec 2021 16:49:44 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFAC3A0CE7 for <apn@ietf.org>; Mon, 13 Dec 2021 16:49:43 -0800 (PST)
Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JCfmZ6dt9z67yqt; Tue, 14 Dec 2021 08:45:18 +0800 (CST)
Received: from canpemm500008.china.huawei.com (7.192.105.151) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.20; Tue, 14 Dec 2021 01:49:39 +0100
Received: from canpemm500008.china.huawei.com (7.192.105.151) by canpemm500008.china.huawei.com (7.192.105.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Tue, 14 Dec 2021 08:49:38 +0800
Received: from canpemm500008.china.huawei.com ([7.192.105.151]) by canpemm500008.china.huawei.com ([7.192.105.151]) with mapi id 15.01.2308.020; Tue, 14 Dec 2021 08:49:37 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: Hesham ElBakoury <helbakoury@gmail.com>, "apn@ietf.org" <apn@ietf.org>
Thread-Topic: [Apn] APN Policy Enforcement
Thread-Index: AQHX78nDufhgIFEF0kCOaHeTjYCBhqwv2Y+Q
Date: Tue, 14 Dec 2021 00:49:37 +0000
Message-ID: <45a2e8e43cc348b9b1ace205109fe48b@huawei.com>
References: <CAFvDQ9pCHx405e-qOm_wHesaLWcsv_RQQNizdZus91dRuRe5=A@mail.gmail.com>
In-Reply-To: <CAFvDQ9pCHx405e-qOm_wHesaLWcsv_RQQNizdZus91dRuRe5=A@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.41.150]
Content-Type: multipart/alternative; boundary="_000_45a2e8e43cc348b9b1ace205109fe48bhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/Sn1PXmwlw3FJVGMkG1ptehdsqFA>
Subject: Re: [Apn] APN Policy Enforcement
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Dec 2021 00:49:49 -0000

Hi Hesham,

Currently, the APN ID is the key field to be checked against for finding the policy to be applied to the traffic. APN Para and Intent are optional.

The comparison on the lengths of both the APN ID and the 5 tuples is not the key. The focal point should be their locations. The 5 tuples are located in various places in a packet. For example, when it is an IPv6 packet with extension headers, the transport layer information is being pushed very deep. In this case, it become very hard to resolve the 5 tuples. While APN ID is in a single location it will be relatively easier to be checked.

It will depend on how we are going to define the intent. In the current draft https://datatracker.ietf.org/doc/html/draft-li-apn-header-00, the intent is defined as follows,
   Intent: A 32-bit identifier, represents a set of service requirements
   to the network.

Compared to the APN Parameters, this intent is a more high-level abstract requirement to the network, e.g. low-latency. To my understanding, it does not directly carry the policies to be enforced but only requirements. But policies are somehow related with the requirements.

Your proposal does sound interesting. Would you like to elaborate more? What is the background of your proposal? Why people want to avoid configuring policies to PEP? Due to what limitations or any reasons? Do you have any thoughts on how to embed these policies as part of the intent field?

Thank you!

Best regards,
Shuping




From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Hesham ElBakoury
Sent: Monday, December 13, 2021 10:32 AM
To: apn@ietf.org
Subject: [Apn] APN Policy Enforcement

Hi,

My understanding from APN drafts is that policies are defined at Policy Definition Point (PDP) and get configured in Policy Enforcement Points  (PEP) using CLI or SDN or distributed to PEP using a protocol.

When a PEP receives a packet what fields in APN header it uses to find the right policy to apply to the packet? One of the main APN goals is to avoid using DPI or 5-tuple to find the right policy to use. Therefore, the length of these fields in APN header should be much shorter than the length of the 5-tuple.

To avoid configuring policies to PEP, can the entry point of the APN domain embed these policies in the APN header ? For example these policies can be part of the Intents field of the header.

Thanks
Hesham