RE: Issues to be closed #33-#38

[Adrian Farrel <[e-mail]>]

Hi Shuping,

 

I think I missed responding to this. Thanks for your patience.

 

> All the issues to be closed are going to be listed in this link

> https://github.com/APN-Community/Issues/issues. 

> Following the issues we posted before, we post our responses

> to the issues #32-#38 this week. These issues are the last set

> of issues summarized in the Chairs' Summary section at the

> end of the BoF. Thanks to the Chairs for their sharp and clear

> summary which have captured almost all the key issues over

> the BoF. 

 

I really like your mode of work here: driving through the issues but raising
them on the list to ensure that there is visibility.

 

> Please either leave your comments in the mailing list or directly

> in the github, so we can finally close these issues. Thank you!

 

Responses and thoughts in line.

 

> 33. Why APN is needed when there are multiple existing

> mechanisms, just as DetNet and Network Slicing? #33

> https://github.com/APN-Community/Issues/issues/33 

> 

> In the latest version of this gap analysis draft 

>
https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis-03,

> a few new subsections have been added to further

> clarify the differences between APN and the existing

> mechanisms such as DetNet and Network Slicing which

> are both resource partitioning techniques.

 

This is a really important distinction between resource partitioning and
traffic steering.

I see Sections 6.7 (DetNet) and 6.8 (Network Slicing), and these are fine
(IMHO) descriptions of the uses of identifiers in those technologies. 

But I don't see the term "resource partition" anywhere. The term "steering"
is used well in the scope discussion.

You may find a reference to draft-ietf-teast-rfc3272bis helpful to
distinguish these different concepts.

 

(Although, maybe some of this belongs in the APN framework draft.)

 

By the way, while I had the draft open, I notice you're using the old
version of the BCP 14 boilerplate, and you need to move it from the document
header down into Section 2.1

 

> 34. How privacy affects APN, especially about accidental breach

> of privacy and subversion of decapsulation? #34

> https://github.com/APN-Community/Issues/issues/34 

> 

> This draft https://datatracker.ietf.org/doc/draft-li-apn-framework/

> specifies that the APN marking will be encapsulated in the outer

>tunnel encapsulation and removed together with the tunnel

> encapsulation at the end of each tunnel. In the same draft, we

> have also listed the APN Attribute Conveying Requirements

>
https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04#section-5.1,

> the [REQ 1d] is that "APN ID MUST be acquired from the

> existing available information of the packet header without

> interference into the payload." APN works within a limited

> domain and the APN ID will be only meaningful to this network

> domain. The interpretation of the values of these fields is a local

> matter within the APN domain.

 

Parts of this are very good.

-          The APN ID does not use information from within the packet
payload

-          The APN ID only uses information from the packet header

-          The context of the APN ID is limited to within the APN domain

 

However, the APN ID is set according to policies within the domain. For
example, the policy may be that a certain pair of sender/receiver addresses
comprise a priority flow between prestigious users. That policy would be
converted to a specific APN ID (or more likely APN Attribute including an
APN ID) that would get special treatment in the network. So an attacker
might learn about the APN markings that indicate priority traffic, spot such
packets, and look to see who is sending/receiving them.

 

Thus, the really important part of what you have said is that APN is only
applied to an edge-to-edge IP-in-IP encapsulation. That is, you tunnel
across the APN domain.

What that means is that the source and destination addresses of the packet
are the end points of the tunnel (i.e., the domain edges), and nothing about
the payload source and destination can be deduced.

 

Furthermore (and I don't think you say this), encryption could be used on
the encapsulated packet as it is carried across the APN domain. That would
mean that someone inspecting a packet, discovering it is receiving "gold"
treatment, and trying to work out who/what qualifies as "gold" would not be
able to see the end-to-end packet.

 

This substantially reduces the privacy concerns.

 

I still wonder whether the write-up of these points could be clearer and
easier. It is enough that you have addressed all the issues, but it is
better if the reader can see the concern and then be lead step by step
through the solution.

 

> 35. Use cases need to explain more about what is needed from the APN

> attribute and what policies are applied in the network. We need more

> detailed "killer" use case examples. #35

> https://github.com/APN-Community/Issues/issues/35 

> 

> In the latest version of this draft

> https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04
<https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04#section-6>
,

> we provided an illustration section introducing a concrete

> use case, which covers the APN ID design, the APN ID configuration

> at the network edge, and the SLA guarantee in the backbone

> network such as network measurement and traffic steering.

> The benefits of using APN in this use case are also introduced. 

 

Yes! That was what was needed.

 

> Several concrete use cases that could benefit from APN have

> also been recorded in IETF drafts and already presented in previous

> meetings. 

> - https://tools.ietf.org/html/draft-liu-apn-edge-usecase  

> - https://tools.ietf.org/html/draft-zhang-apn-acceleration-usecase  

> - https://tools.ietf.org/html/draft-yang-apn-sd-wan-usecase 

 

These are good documents, but what they don't do is say "Therefore we need
the APN Attribute to carry the following information."

 

> 36. The APN attribute should not become a way of carrying

> arbitrary metadata. It is not clear at this stage what information

> needs to be in the APN attribute versus what information could

> be in the APN attribute. #36

> https://github.com/APN-Community/Issues/issues/36   

> 

> Yes, we agree that the APN attribute should not become a way

> of carrying arbitrary metadata. The APN Header is specified in

> this draft https://datatracker.ietf.org/doc/draft-li-apn-header/. 

> The carried APN ID and the APN Parameters are also defined. 

> The APN Attribute Conveying Requirements are also specified

> in this draft
https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04#section-5.1.

 

Right, so the header draft defines a field that can contain APN parameters.
This is, free-format data and you can understand why some people might think
that *any* data could be included in there.

 

In fact, the content of the APN-Para field is determined by the setting of
the APN-Para-Type field (a 16 bit field) enabling 16 different parameter
formats to be defined and included. 

 

What stops me writing a draft tomorrow describing bit 7 to mean "User's home
phone number, height, shoe size, computer serial number"? Or any other
meta-data? Indeed, why would I even need to write a draft?

 

So, there is another constraint: each APN Parameter field is exactly 32
bits. That means I would need several fields to carry my metadata. But
still, the option is open.

 

I think you can tighten this up by:

-          Asking for an IANA registry to track the bits

-          Making the assignment policy for that registry "IETF Review"

 

This does not stop arbitrary metadata, but it gives the IETF control over
it.

 

You might also describe the expected behavior when an APN-Para-Type field is
set and the processing node does not understand the meaning. I think that,
because each Parameter field is 32 bits, I can simply ignore and step over
the parameters I don't understand.

 

> 37. We also need more understanding of how APN is

> relevant in encrypted environments.  #37

> https://github.com/APN-Community/Issues/issues/37 

> 

> The APN attribute is acquired based on the existing information in

> the packet header such as 5-tuple (might be 2-tuple in an encrypted

> environment) and QinQ (S-VLAN and C-VLAN) at the edge devices of

> the APN domain, added to the data packets along with the tunnel

> encapsulation. This means that APN does not need to rely on the

> encrypted payload of the packet. Moreover, in this draft

>
https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04#section-5.1,

> we have also listed the APN Attribute Conveying Requirements,

> the [REQ 1d] is that "APN ID MUST be acquired from the existing

> available information of the packet header without interference

> into the payload." 

 

Right. It is not just the encryption of the payload, but those three fields
of the 5-tuple.

As you say, if there is encryption, the APN processing will be limited to
less information.

 

I suggest that you turn the text the other way round so that you say that
APN processing is based on:

-          Source and destination addresses

-          Incoming L2 (or MPLS) encapsulation

-          Incoming physical/virtual port information

-          The other fields of the 5-tuple if they are not encrypted

 

I think you also have to say that if the APN packet is itself encrypted
(e.g., the APN tunnel across the APN domain uses IPsec) then the APN
Attribute MUST NOT be encrypted.

 

> 38. Should APN be applied to multiple transport/underlay protocols

> or should it be better to pick just one and use it in all APN-enabled 

> networks? #38

> https://github.com/APN-Community/Issues/issues/38 

> 

> Currently the APN Header and its encapsulation in the IPv6 data plane

> are described in https://datatracker.ietf.org/doc/draft-li-apn-header/ 

> and https://datatracker.ietf.org/doc/draft-li-apn-ipv6-encap/, 

> respectively.

> 

> We want to focus on the IPv6 data plane where we believe APN will

> be most useful. However, in developing the APN Header, we want to

> do it in a generic way so that it is available for use in other data plane

> encapsulations should that turn out to be valuable. Designing a

> generic APN Header will not damage its value and use in IPv6, and 

> seems to be the correct architectural solution to be future-proofed

> and most useful within the IETF.

 

I agree with this approach. It seems sensible.

 

It would be good to be sure that the drafts say this clearly.

 

Thanks,

Adrian