Subject: Roman Danyliw's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 09 Aug 2021 13:49:37 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-6man-ipv6-alt-mark-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please provide consistent guidance on where this methodology can be used. 
Consider:

(a) Section 2.1. “Therefore, the IPv6 application of the Alternate Marking
Method MUST NOT be deployed outside a controlled domain.”

(b) Section 2.1.  “Some scenarios may imply that the Alternate Marking Method
is applied outside a controlled domain, either intentionally or
unintentionally, but in these cases, IPsec authentication and encryption MUST
be used.”

(c) Section 6. “This document aims to apply a method to perform measurements
that does not directly affect Internet security nor applications that run on
the Internet.”

(d) Section 6. “As stated above, the precondition for the application of the
Alternate Marking is that it MUST be applied in specific controlled domains,
thus confining the potential attack vectors within the network domain.

(e) Section 6. “In this case, the user, aware of the kind of risks, may still
want to use Alternate Marking for telemetry and test purposes but the
inter-domain links need to be secured (e.g., by IPsec) in order to avoid
external threats.  For these specific scenarios the application of the
Alternate Marking Method outside a controlled domain is possible but IPsec
through AH    (Authentication Header) or ESP (Encapsulating Security Payload)
MUST be used.”

(a) and (d) seem to very clear that this approach MUST only be used in a
controlled domain.  However (b) and (d) seem to suggest that this prohibition
is at best a “SHOULD”.  If (b) and (d) are true, than (c) not affecting
applications on the internet might not be true.

** Section 6.  Thanks for mentioning “At the management plane, attacks can be
set up by misconfiguring or by maliciously configuring AltMark Option.”  Please
be clearer on what these attacks could look like.  Would these include:

-- using the FlowMonId as a tracking identifier?

-- (Likely possible at both the data and management plane would be a) covert
channel between the sender and an on-path observer?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Chris Wood for the SECDIR review and to the authors for responding
to it.

** Is those a tighter applicability statement than can be applied where this
approach will be used.  A few things are said:

(a) Section 1. “As for all the on-path telemetry technique, the only definitive
solution is that this methodology MUST be applied in a controlled domain ...”

(b) Section 1. “... therefore the application to untrusted domain is NOT
RECOMMENDED”

(c) Section 6. “As stated above, the precondition for the application of the   
Alternate Marking is that it MUST be applied in specific controlled   domains,
thus confining the potential attack vectors within the network domain. 
[RFC8799] analyzes and discusses the trend towards network behaviors that can
be applied only within a limited domain.”

-- While citing RFC8799 is helpful as the basis of phrase “controlled domain”,
that reference also explains that “The requirements of limited domains will
depend on the deployment scenario.  Policies, default parameters, and the
options supported may vary.  Also, the style of network management may vary
between a completely unmanaged network, one with fully autonomic management,
one with traditional central management, and mixtures of the above.  Finally,
the requirements and solutions for security and privacy may vary.”  Put in
another way, unless further specified, RFC8799 doesn’t actually say anything
about the properties of the network except that it isn’t the Internet.  Will it
be a managed network? A single administrative domain? Etc.

-- Per (b), stating “untrusted domain” (thanks for responding to the SECDIR
reviewer with this) is orthogonal to “controlled domain”.  Being  “controlled”
doesn’t suggest “trusted” or “untrusted”.  Can “untrusted” be elaborated on?

** Section 2.1.  Per “Some scenarios may imply that the Altenative Marking
Method is applied outside a controlled domain ... unintentionally, ...”, it
seems odd to provide normative guidance for unintentional behavior.

** Section 2.1.  Per “It is RECOMMENDED that an implementation can be able to
reject packets that carry Alternate Marking data and are entering or leaving
the controlled domains”, what is the “implementation” in this case?  I was
under the impression that these are end-node applying this marking.  However,
it seems like routers/firewalls would be the ones enforcing the policy of
dropping these packets.

** Section 5.3.  Per “The FlowMon identifier field is to uniquely identify a
monitored flow within the measurement domain”, what is a measurement domain?
What is the relationship between it and the controlled domain in which it is
supposed to be operating?  Perhaps there is a definition for “measurement
domain” that can be cited?

** Section 6.
   As
   already discussed in Section 4, it is RECOMMENDED that the AltMark
   Option does not affect the throughput and therefore the user
   experience.

This text appears to be stating a desired functional requirement of the AltMark
not having an impact on the network, but the practical guidance to an adopter
isn’t clear to me.

** Various editorial comments

-- Section 1.  Editorial. Per “The Alternate Marking is an on-path telemetry
technique and consists in synchronizing …", there is a grammar nit with “...
and consists in synchronizing ...” but I don’t follow the intent enough to
provide a suggestion.

-- Section 5.1. Editorial.  Per “The measurement of the packet loss is really
straightforward”, straightforward in comparison to what?

-- Section 5.1.  Editorial.  s/and and/and/

-- Section 5.3.  Editorial.  s/if the/If the/

-- Section 6.  Editorial.  s/or insert deliberately/or deliberately insert/

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 10 Aug 2021 13:00:56 +0000

Dear Roman,
Thanks for your review. 
Please find my replies inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Roman Danyliw via Datatracker <[email-masked]> 
Sent: Monday, August 9, 2021 10:50 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Roman Danyliw's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS and COMMENT)

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

(a) Section 2.1. “Therefore, the IPv6 application of the Alternate Marking Method MUST NOT be deployed outside a controlled domain.”

(b) Section 2.1.  “Some scenarios may imply that the Alternate Marking Method is applied outside a controlled domain, either intentionally or unintentionally, but in these cases, IPsec authentication and encryption MUST be used.”

(c) Section 6. “This document aims to apply a method to perform measurements that does not directly affect Internet security nor applications that run on the Internet.”

(d) Section 6. “As stated above, the precondition for the application of the Alternate Marking is that it MUST be applied in specific controlled domains, thus confining the potential attack vectors within the network domain.

(e) Section 6. “In this case, the user, aware of the kind of risks, may still want to use Alternate Marking for telemetry and test purposes but the inter-domain links need to be secured (e.g., by IPsec) in order to avoid external threats.  For these specific scenarios the application of the Alternate Marking Method outside a controlled domain is possible but IPsec
through AH    (Authentication Header) or ESP (Encapsulating Security Payload)
MUST be used.”

(a) and (d) seem to very clear that this approach MUST only be used in a controlled domain.  However (b) and (d) seem to suggest that this prohibition is at best a “SHOULD”.  If (b) and (d) are true, than (c) not affecting applications on the internet might not be true.

[GF]: Yes, the fundamental requirement is that Alternate Marking MUST be applied in a controlled domain, as explained in (a) and (d). To avoid misunderstanding, we could also omit the considerations (b) and (e). We just wanted to highlight that in specific cases, if you are aware of the risks of this on-path telemetry technique, you may still want to apply Alternate Marking for the e2e service and consequently outside a controlled domain; but in this case IPsec is RECOMMENDED.

** Section 6.  Thanks for mentioning “At the management plane, attacks can be set up by misconfiguring or by maliciously configuring AltMark Option.”  Please be clearer on what these attacks could look like.  Would these include:

[GF]: We already mentioned that FlowMonID field represents a sensitive information for network reconnaissance and may allow a flow tracking type of attack because an attacker could collect information about network paths. But the application to a controlled domain helps to mitigate this issue as well.

-- (Likely possible at both the data and management plane would be a) covert channel between the sender and an on-path observer?

[GF]: Good suggestion. In RFC 8321 we mentioned that it might be theoretically possible to modulate the marking to serve as a covert channel. We can add some consideration in relation to both data and management plane also in this document.

Thank you to Chris Wood for the SECDIR review and to the authors for responding to it.

** Is those a tighter applicability statement than can be applied where this approach will be used.  A few things are said:

(a) Section 1. “As for all the on-path telemetry technique, the only definitive solution is that this methodology MUST be applied in a controlled domain ...”

(b) Section 1. “... therefore the application to untrusted domain is NOT RECOMMENDED”

(c) Section 6. “As stated above, the precondition for the application of the   
Alternate Marking is that it MUST be applied in specific controlled   domains,
thus confining the potential attack vectors within the network domain. 
[RFC8799] analyzes and discusses the trend towards network behaviors that can be applied only within a limited domain.”

-- While citing RFC8799 is helpful as the basis of phrase “controlled domain”, that reference also explains that “The requirements of limited domains will depend on the deployment scenario.  Policies, default parameters, and the options supported may vary.  Also, the style of network management may vary between a completely unmanaged network, one with fully autonomic management, one with traditional central management, and mixtures of the above.  Finally, the requirements and solutions for security and privacy may vary.”  Put in another way, unless further specified, RFC8799 doesn’t actually say anything about the properties of the network except that it isn’t the Internet.  Will it be a managed network? A single administrative domain? Etc.

[GF]: Yes, in addition to RFC8799, we also tried to add more details in Section 6: "A limited administrative domain provides the network administrator with the means to select, monitor and control the access to the network, making it a trusted domain.  In this regard it is expected to enforce policies at the domain boundaries to filter both external packets with AltMark Option entering the domain and internal packets with AltMark Option leaving the domain.  Therefore the trusted domain is unlikely subject to hijacking of packets since packets with AltMark Option are processed and used only within the controlled domain.". So a controlled domain is a managed network and it does not necessarily mean that it is a single administrative domain. We can clarify this in Section 2.1, so it is of benefit to the reader.

-- Per (b), stating “untrusted domain” (thanks for responding to the SECDIR reviewer with this) is orthogonal to “controlled domain”.  Being  “controlled”
doesn’t suggest “trusted” or “untrusted”.  Can “untrusted” be elaborated on?

[GF]: Maybe we can add more details here. Untrusted domain means the Internet or wherever the security concerns cannot be mitigated by using IPsec or by applying the control at the domain boundaries. 

** Section 2.1.  Per “Some scenarios may imply that the Altenative Marking Method is applied outside a controlled domain ... unintentionally, ...”, it seems odd to provide normative guidance for unintentional behavior.

[GF]: Agree. I will definitely remove that sentence.

** Section 2.1.  Per “It is RECOMMENDED that an implementation can be able to reject packets that carry Alternate Marking data and are entering or leaving the controlled domains”, what is the “implementation” in this case?  I was under the impression that these are end-node applying this marking.  However, it seems like routers/firewalls would be the ones enforcing the policy of dropping these packets.

[GF]: If the end-node is fully managed and it is within the controlled domain, it can implement the method. But this is not common. So the implementation can be done starting from the first router (CPE) that can be able to filter and drop packets. I can add more details in the next version.

** Section 5.3.  Per “The FlowMon identifier field is to uniquely identify a monitored flow within the measurement domain”, what is a measurement domain?
What is the relationship between it and the controlled domain in which it is supposed to be operating?  Perhaps there is a definition for “measurement domain” that can be cited?

[GF]: Agree. In most of the cases it overlaps with the controlled domain but it may also happen that the measurement domain is a subset of the controlled domain. I will clarify this point.

** Section 6.
   As

This text appears to be stating a desired functional requirement of the AltMark not having an impact on the network, but the practical guidance to an adopter isn’t clear to me.

[GF]: This refers to current implementation of Hop-by-Hop Options as explained in Section 4: "in practice, it is important to be aware for the implementation that the things may be different and it can happen that packets with Hop-by-Hop are forced onto the slow path, but this is a general issue, as also explained in [I-D.hinden-6man-hbh-processing]." I will clarify this point as well.

-- Section 1.  Editorial. Per “The Alternate Marking is an on-path telemetry technique and consists in synchronizing …", there is a grammar nit with “...
and consists in synchronizing ...” but I don’t follow the intent enough to provide a suggestion.

[GF]: Ok, I will revise the sentence

-- Section 5.1. Editorial.  Per “The measurement of the packet loss is really straightforward”, straightforward in comparison to what?

[GF]: It is in comparison to the existing mechanisms. More details are in RFC 8321. I will add the reference.

[GF]: Ok

[GF]: Ok

[GF]: Ok