Re: [Apn] Further revised draft Charter

Hi Ted,

    Some personal opinions here. Hope it can help.

    APNET Field is used to carry more information in the packet so that various network services can be provided to the tenants more easily. We think APNET is solving an imminent problem of deploying various network services in scale. 

    I agree with you that more information would be provided in the APN packets. However, IMO, not all traffic are needed to be marked with the APN bits. I think that the APN packets are just for specific flows that have a special SLA requirement. Meanwhile, proper encryption mechanisms can mitigate the problem perhaps.

    About the architectural side, IMO, I think the APN marking is more flexible and straightforward. It can provide a data-driven on-demand APN triggered policy. As I have said before, not all the traffic need to be APN marked.

    The signals you mentioned last means the APN marking? I agree that the information carried in APN bits is actually flow oriented. But the trusting and restricting problems should be solvable. 

Best Regards
Zongpeng Du

duzongpeng@foxmail.com & duzongpeng@chinamobile.com

From: Ted Hardie
Date: 2023-01-18 17:16
To: Donald Eastlake
CC: apn; apn-chairs
Subject: Re: [Apn] Further revised draft Charter
Hi Donald,

I've read the new charter, and I continue to have both privacy concerns and architectural doubts.  On the privacy side, you note that there are a variety of services which might be required ranging from routing to prioritization and measurement.  The larger the number of services, the more likely it is that a specific combination can be used to fingerprint traffic in ways that become problematic.  I'm sure you're aware of the literature on this from the web world relating to headers and font selection, so I won't belabor it too much, but I feel the open-endedness of this field is problematic.  As I read this, an APNET domain could either put a large collection of data into the field that becomes a fingerprint, a hash of it that would also serve as a fingerprint, or even decide to put a customer identifier in that field and then let each router or middlebox on the path lookup the appropriate behavior.  While you might argue that either that the hash of that cluster or a customer identifier would be opaque, third party attackers would get at least uniqueness data that they would not otherwise have, contrary to efforts by the end system to use private IP addressing or similar approaches.

On the architectural side, there are a number of fields that already do elements of what this charter lists as desiderata (QoS, routing, etc.)--why is creating an omnibus field for all of them going to work better than acting on the ones that are already there?  Stepping back a bit, If you were to look back at the OPES considerations in RFC 3238, how would you distinguish this from that approach, and why would the considerations be different?  That recommended at least one party consent and directly addressed intermediaries, neither of which this seems to provide.  

To put this a differently, this work seems to want flow based path signals without trusting the endpoint and without restricting the scope of those signals.  Neither seems to me the best approach  

regards,

Ted

On Wed, Jan 18, 2023 at 2:04 AM Donald Eastlake <d3e3e3@gmail.com> wrote:
I've gotten some comments and I've re-read some of the AD DISCUSSES and comments. Based on that I've updated the draft Charter as attached.  Comments are welcome. 

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3@gmail.com
-- 
Apn mailing list
Apn@ietf.org
https://www.ietf.org/mailman/listinfo/apn