Definition of Transparency

There were two comments during the presentation at IETF 106 that proposed adding a transparency property.

Joachim Fabini: I find it interesting to have a property of a layer X transparency, so we could have a property on a specific layer, if you're transparent for a given layer then you have an end-to-end conversation between the adjacent non-transparent nodes. Theresa: Could you find a reference for that and post it to the list, I'd like to take a list at how you mathematically express those. Joachim: For security, is there any property about security/encryption at a specific layer? Theresa: I could imagine talking about trust in some way, that's really complicated, I'm not sure you want to cover how much you trust a specific path element as a given property. You would always have to qualify it, and encryption is not the same as encryption. Joachim: Encryption could be done from end nodes to end nodes Theresa: I'm not sure I'm defining a threat model in there, though. The trust question is really interesting and we should revisit it

Mirja: Plus one on adding transparency or definition of transparency, but don't need to decide before adoption.

We changed the path definition in this revision by changing from "hiding path elements on a higher layer" to "having partial visibility of the path elements" in 4528e8db99aa3138b429d9b48e3f31b33478059a. I'm wondering if the desire for transparency comes from the fact that it is not clear enough that we can define a path on different layers using virtual nodes/links or if each property should define for which layers it is visible/transparent. The former we could fix by rephrasing the path definition, but the latter would require extending the property definition.

I'm not a big fan of extending the property definition since this would require us to also define layers which I'm not sure how to do (OSI, end-to-end vs not end-to-end, ...?)

We changed the path definition in this revision by changing from "hiding path elements on a higher layer" to "having partial visibility of the path elements" in 4528e8d.

For me, our current definition of a path "having partial visibility of the path elements […] and entities may treat path elements at different levels of abstraction" is not really about layering, but more related to knowing what exact elements are on a path (e.g., specific routers) VS just knowing that there's some AS or otherwise amorphous "abstract nodes". I think this related to layering, but not really what these comments meant. I think we removed the layering part from our path definition to simplify the definition and because we didn't think it was well-defined and people hadn't indicated they wanted it. However, now this has changed...

I'm wondering if the desire for transparency comes from the fact that it is not clear enough that we can define a path on different layers using virtual nodes/links or if each property should define for which layers it is visible/transparent.

I think this is not about the definition of a path on different layers, so we don't have to change the path definition. I also do not think this is a per-property thing, so we don't need to change the definition of a property. I think this is about, e.g., first defining/knowing about a path "on a low layer" (for example, all nodes that read the IP header and the links between these nodes), and then talk about path elements that do not look further into the packet such as the TCP header (= path elements that are layer 4 transparent) VS path elements that do look at the TCP header (= layer 4 not transparent). Or maybe path elements that modify the TCP header VS path elements that do not modify it.

In the session, I think the desire to define "layer x transparency" goes back to the initial comment that Tommy made: Can we express somehow that a node on the path allows me [the host] to make choices, participates in some measurement, enables path selection, etc? Tommy proposed to have a definition for nodes which let the host do something like this VS nodes which do not. I said that maybe this should rather be another property, and that we already have a property for "this node can do something specific to the packets" (Service Function). Then, Brian said he does not want us to do node classification in this document (which I guess refers to Tommy's suggestion), but there's room to talk about classes of functions a node provides, and then he started talking about transparency on a specific layer. Here I agree with Brian that we should be careful not to try to define every possible Service Function that a path element might have, but be generic.

All in all, I think we should not change our definitions based on this. However, we should consider adding a property saying "this node does or does not [look/modify a packet header/payload on a specific layer]". Maybe call it "transparency", maybe call it something else. This could be similar to our Service Function property, "this node provides a certain service function", and then we give a few examples what this could be, but do not try to enumerate all possible functions.

Instead of defining OSI layers, we could just talk about "the IP-layer" (which we already do in the property definitions based on IPPM), "the transport layer", and "the application layer", or we could simply talk about different protocols within a packet (an IP header, a TCP header, ...).

This all becomes much more complicated with encapsulation, but I'm not sure we have to make this our problem, but let the Research Group think about it. After all, this is a Research Group document now, so everyone's responsible. ;)

Further comments on transparency in the June 2020 PANRG interim:

    - Brian: […] Previous life worked on path transparency. Transperency might be
    looking at headers without changing them and that can affect protocols.
    There might be more shades of grey, at least three. Add some nuance.
    (Cyril: blocking or not blocking) Yes, that as well. Other kinds of
    behavior changes as well.

So let's add some nuance. Not sure about the specific content to add though.

Jake's review and my reply:

3. I had a slightly hard time with the Transparency example in Examples of Path Properties:

Transparency:  A node is transparent with respect to a protocol
   header, payload, or both for a specific action if the node
   performs this action independently of the given
   (meta-)information.  Actions can for example be blocking packets
   or reading and modifying (other protocol) headers or payloads.  An
   IP router could be transparent for transport protocol headers such
   as TCP and UDP, in contrast to a NAT that actively modifies TCP
   and UDP header information.

Is it correct to say that in this usage, Transparency is defined only in relation to flow properties?

Transparency is defined in relation to a particular flow. Not sure if it's necessarily "in relation to flow properties", as I wouldn't say that a protocol header itself is necessarily a flow property. But I guess the presence of a header, or of a header field, could be a flow property. For example, we already have a "Protocol Features available" property for features like ECN, and now one could define the actual presence/usage of ECN as a flow property.

Is it correct that "block all TCP Syn packets" is transparent with respect to IP but not with respect to TCP? (Or does relying on the protocol type already break that? And if so, is that still transparent with respect to the TCP payload?)

I think our Transparency definition does not yet go into that level of detail, but answering questions like these will refine it.

As a first proposal, I would say that blocking packets is not transparent to any part of a flow, as it prevents the entire flow from actually traversing the path. Therefore, it wouldn't be transparent with respect to IP either.

Would you agree with that?

Cyrill, do you have more thoughts on this, as you originally added the text for this Property?

Is it also correct that a NAT is transparent with respect to payloads, but not transparent with respect to IP, TCP, or UDP headers?

Generally, yes.

We refined the Transparency definition to include different "degrees" of transparency with respect to a specific action. For example, NAT may not be transparent with respect to reading IP and TCP or UDP headers, but it could be transparent with respect to modifying TCP/UDP headers if it does not change port numbers (which might not be common or a good example - but I'm sure there's several on-path nodes that may read headers, but not modify them).

So I guess a specific path element can be "read-transparent" with respect to some parts of a packet/flow, and "modify-transparent" with respect to other (fewer) parts of a packet/flow.

Does that make sense?

(If I got all that right, I feel like saying a few sharper examples along these lines would help to clear it up better. If not, I guess I'm too confused to know what to suggest, and I think it needs clarifying.)

I agree that adding examples will be good.

Comment from Med and my reply:

 [Med] FWIW, another common usage of "transparent" is when a network function is invoked without requiring any signaling from the endpoints (unlike explicit mode) and while its presence is not easily detected by the endpoints (e.g., transparent proxies).

It would be useful if the overlap with the common usage is clarified/avoided. Thank you.

[TE] RFC 2616 defines a transparent proxy as "a proxy that does not modify the request or response beyond what is required for proxy authentication and identification." Is this the definition you'd use as well, or are you referring to a different definition?

For the RFC 2616 definition, I think our Transparency definition actually covers that - if the proxy neither blocks nor modifies the HTTP payload, it is transparent to these parts of the packet, but it does potentially modify other parts of the packet. Also, it most likely terminates the TCP connection, so it isn't transparent to any protocol that is lower in the stack than HTTP. Do you agree? Maybe this could be one clarifying example.

Beyond the transparent proxy, I'm wondering if "This node explicitly communicates with the endpoint" is another type of (Non-)Transparency, next to "block", "modify", and "read". Explicit communication between node and endpoint perhaps already means that the node modifies packets, but it's a bit more high-level, talking about the semantics of the modification, and implies intention. Maybe it's a separate property. This might be useful to have, but maybe it's too difficult to accurately model. But maybe talking about implicit VS. explicit signalling can be helpful, possibly referring to RFC 8558?

Further replies:

[TE] RFC 2616 defines a transparent proxy as "a proxy that does not modify the request or response beyond what is required for proxy authentication and identification." Is this the definition you'd use as well, or are you referring to a different definition?

[Med] I'm afraid that some functions that are "traged" as transparent in operational networks are doing more than that. For example, in mobile network there are functions that inject/strip headers (HTTP headers), TCP options, etc.

For the RFC 2616 definition, I think our Transparency definition actually covers that - if the proxy neither blocks nor modifies the HTTP payload, it is transparent to these parts of the packet, but it does potentially modify other parts of the packet. Also, it most likely terminates the TCP connection, so it isn't transparent to any protocol

[Med] I think we could reason in term of "transparency to endpoints" in general, not only to a protocol.

that is lower in the stack than HTTP. Do you agree? Maybe this could be one clarifying example.

[Med] This would be useful, indeed.

Beyond the transparent proxy, I'm wondering if "This node explicitly communicates with the endpoint" is another type of (Non- )Transparency, next to "block", "modify", and "read". Explicit communication between node and endpoint perhaps already means

[Med] This means that an endpoint accepts whatever "service" that will provided by the node that is explicitly added to the communicated path. This is mainly from the sender standpoint. An interesting feature that we may consider is to associate a remote peer on the "consent" process to involve an intermediate function.

that the node modifies

packets, but it's a bit more high-level, talking about the semantics of the modification, and implies intention. Maybe it's a separate property.

[Med] I agree this is a separate property that it is worth to capture in the I-D.

This might be useful to have, but maybe it's too difficult to accurately model.

[Med] Not sure what you meant by "model".

More replies:

[Med] I'm afraid that some functions that are "traged" as transparent in operational networks are doing more than that. For example, in mobile network there are functions that inject/strip headers (HTTP headers), TCP options, etc.

[TE] I see, thanks for the clarification. Our draft's definition would surely not classify these as transparent with respect to HTTP or TCP, and I agree that it'll be good to clarify this overlap in terminology.

For the RFC 2616 definition, I think our Transparency definition actually covers that - if the proxy neither blocks nor modifies the HTTP payload, it is transparent to these parts of the packet, but it does potentially modify other parts of the packet. Also, it most likely terminates the TCP connection, so it isn't transparent to any protocol [Med] I think we could reason in term of "transparency to endpoints" in general, not only to a protocol.

[TE] How would you define transparency to endpoints? There could be a distinction between whether an endpoint explicitly communicates with the on-path node (e.g., explicit signals as discussed in RFC 8558). Is this the same as the "accepting a service that will be provided" that you mention below?

Beyond the transparent proxy, I'm wondering if "This node explicitly communicates with the endpoint" is another type of (Non- )Transparency, next to "block", "modify", and "read". Explicit communication between node and endpoint perhaps already means [Med] This means that an endpoint accepts whatever "service" that will provided by the node that is explicitly added to the communicated path. This is mainly from the sender standpoint. An interesting feature that we may consider is to associate a remote peer on the "consent" process to involve an intermediate function.

that the node modifies

packets, but it's a bit more high-level, talking about the semantics of the modification, and implies intention. Maybe it's a separate property. [Med] I agree this is a separate property that it is worth to capture in the I-D.

[TE] Yes, I we probably can't capture all nuances in the Path Properties draft.

This might be useful to have, but maybe it's too difficult to accurately model. [Med] Not sure what you meant by "model".

[TE] Oh, this is basically the same point made above: Transparency can be difficult to define and I think a definition based on nodes that can send, receive, forward, or modify packets won't capture all nuances.

Final replies for this thread:

[TE] How would you define transparency to endpoints?

[Med] This can be defined as adding an intermediate function to a communication without an explicit signal/consent from one of the endpoints.

There could be a distinction between whether an endpoint explicitly communicates with the on-path node (e.g., explicit signals as discussed in RFC 8558). Is this the same as the "accepting a service that will be provided" that you mention below?

[Med] Yes.

I slightly changed the transparency definition such that (meta-)information includes the existence of a protocol (header). I added two examples relating to RFC2616 and RFC8558. I also added three examples of (non-)transparency to show the three different possibilities:

IP router: IP non-transparent and TCP/UDP transparent
SYN flood FW: IP transparent and TCP/UDP non-transparent
NAT: IP and TCP/UDP non-transparent

I didn't add an additional property for "endpoint transparency" since I'm not sure we really need it at this point.

What do you think? Do we need to fundamentally change the property definition or is the proposed change enough?

At the IETF 111 PANRG session, there was a discussion around the transparency definition in the chat:

Cyrill: Hi Richard. Thanks for the interesting question/comment. A way we could define the current property mathematically is: modelling a function f that takes as input the different (meta-)information metrics and the packet(s) and outputs the action taken, i.e., f(metrics, pkt). And then transparency would be f(metrics, p1) == f(metrics, p2) for all packets p1 and p2 that only differ in the metric. Richard: This looks good as one possibility, implying constant. In your original doc (e.g., IP vs NAT example), it is the no-taint requirement, in that the function f does not access the metric. In PL/security, it is no taint. It looks that the second one is more what you want. Cyrill: What do you mean with PL/security? Richard: programming language (PL). I mean the technique in that field. Cyrill: Ok, thanks for the pointers. I will look it up to see how it could be applied in our definition. Richard: Sounds good. I will be happy to chat later. Cyrill: Thanks, that would be great.

Should anything change in the transparency definition as a result of this discussion?

panrg / path-properties

Definition of Transparency #25