Subject: Re: FW: I-D Action: draft-ietf-6man-ipv6-alt-mark-13.txt

From: Warren Kumari <[email-masked]>
Date: Wed, 13 Apr 2022 09:39:38 -0700

[ Apologies, I'd thought that I'd sent this on April 2nd, but I just found
it lurking in my drafts… ]

On Thu, Mar 31, 2022 at 3:51 AM, Giuseppe Fioccola <
giuseppe.fioccola=[email-masked]> wrote:

> Dear All,
> Please note that I just updated the draft to include the normative
> references to RFC8321bis and RFC8889bis. As Erik suggested, this should
> help to clear some IESG pending positions in order to move forward the
> document.
>
>

I do not see anything / anywhere where my DISCUSS concerns are addressed,
and I have a suspicion that we walked away from the last exchange both
assuming that the other person understood and agreed —
https://mailarchive.ietf.org/arch/msg/ipv6/5G0qpQ6u2OO9PqpulKl-uuLrv_M/

Let me try and restate my concern (noting that I last read the document in
detail in Aug, 2021):

Section 1.  Introduction says:
"As with all on-path
   telemetry techniques, the only definitive solution is that this
   methodology MUST be applied in a controlled domain."

and then this is repeated in 6.  Security Considerations which says:
"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.
 [...]
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."
and
"Since the measurement itself may be affected by network
   nodes intentionally altering the bits of the AltMark Option or
   injecting Options headers as a means for Denial of Service (DoS), the
   Alternate Marking MUST be applied in the context of a controlled
   domain, where the network nodes are locally administered and this
   type of attack can be avoided.  For this reason, the implementation
   of the method is not done on the end node if it is not fully managed
   and does not belong to the controlled domain.  Packets generated
   outside the controlled domain may consume router resources by
   maliciously using the HbH Option, but this can be mitigated by
   filtering these packets at the controlled domain boundary.  This can
   be done because, if the end node does not belong to the controlled
   domain, it is not supposed to add the AltMark HbH Option, and it can
   be easily recognized."

How are these "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." supposed to be implemented? Current
devices do not understand AltMark, and so I don't see how an operator is
supposed to do this.

You say "For this reason, the implementation of the method is not done on
the end node if it is not fully managed and does not belong to the
controlled domain." - what prevents an attacker (that does not belong to
the controlled domain) from implementing and sending these packets (other
than the assertion that "it is not done")?

In addition, the document says:
" As stated, the application to a controlled domain ensures the control
   over the packets entering and leaving the domain, but despite that,
   leakages may happen for different reasons, such as a failure or a
   fault.  In this case, nodes outside the domain MUST simply ignore
   packets with AltMark Option since they should not process it."

How does a device (like my phone or laptop) know if it is inside or outside
of the domain?

I suspect that we are talking past each other, or that I'm missing
something *very* fundamental here…

W

> Best Regards,
>
> Giuseppe
>
> -----Original Message-----
> From: ipv6 <[email-masked]> On Behalf Of [email-masked]
> Sent: Thursday, March 31, 2022 9:44 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-13.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the IPv6 Maintenance WG of the
> IETF.
>
> Title : IPv6 Application of the Alternate Marking Method Authors :
> Giuseppe Fioccola
> Tianran Zhou
> Mauro Cociglio
> Fengwei Qin
> Ran Pang
> Filename : draft-ietf-6man-ipv6-alt-mark-13.txt Pages : 23
> Date : 2022-03-31
>
> Abstract:
> This document describes how the Alternate Marking Method can be used as a
> passive performance measurement tool in an IPv6 domain. It defines a new
> Extension Header Option to encode Alternate Marking information in both the
> Hop-by-Hop Options Header and Destination Options Header.
>
> The IETF datatracker status page for this draft is: https://datatracker.
> ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-13
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-alt-mark-13
>
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
>
>
> -------------------------------------------------------------------- IETF
> IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>

---

From: Giuseppe Fioccola <[email-masked]>
Date: Wed, 13 Apr 2022 17:53:22 +0000

Hi Warren,
Thank you for resuming the revision.
Please find my answers inline tagged as [GF].

Regards,

Giuseppe

From: Warren Kumari <[email-masked]>
Sent: Wednesday, April 13, 2022 6:40 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: [email-masked]; Erik Kline <[email-masked]>; The IESG <[email-masked]>
Subject: Re: FW: I-D Action: draft-ietf-6man-ipv6-alt-mark-13.txt

[ Apologies, I'd thought that I'd sent this on April 2nd, but I just found it lurking in my drafts… ]

On Thu, Mar 31, 2022 at 3:51 AM, Giuseppe Fioccola <giuseppe.fioccola=[email-masked]<mailto:giuseppe.fioccola=[email-masked]>> wrote:
Dear All,
Please note that I just updated the draft to include the normative references to RFC8321bis and RFC8889bis. As Erik suggested, this should help to clear some IESG pending positions in order to move forward the document.

I do not see anything / anywhere where my DISCUSS concerns are addressed, and I have a suspicion that we walked away from the last exchange both assuming that the other person understood and agreed — https://mailarchive.ietf.org/arch/msg/ipv6/5G0qpQ6u2OO9PqpulKl-uuLrv_M/

Let me try and restate my concern (noting that I last read the document in detail in Aug, 2021):

How are these "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." supposed to be implemented? Current devices do not understand AltMark, and so I don't see how an operator is supposed to do this.

[GF]: As any other Hop-by-Hop Options or Destination Options, an operator that implements AltMark can discard/ignore/remove AltMark Options entering the domain (e.g. by using ACL extensions for filtering). In any case, if an operator does not update its ACLs and does not implement AltMark, there is no side effect since AltMark is treated as any other unrecognized option and will not be considered by the nodes since they are not configured to deal with it. Maybe I can further clarify in the next version.

You say "For this reason, the implementation of the method is not done on the end node if it is not fully managed and does not belong to the controlled domain." - what prevents an attacker (that does not belong to the controlled domain) from implementing and sending these packets (other than the assertion that "it is not done")?

[GF]: Yes, an attacker can send packets with AltMark option. But if the operator does not implement AltMark, no problem happens since the option is ignored and the only effect is the increased MTU (by 48 bits). While if the operator implements AltMark, it is also supposed to avoid that the measurements are affected so it should ignore external packets with AltMark option. I can also explain this point in the next version.

How does a device (like my phone or laptop) know if it is inside or outside of the domain?

[GF]: A phone or a laptop simply ignores that option since it is not configured to handle it. As said, the only effect is an MTU increased by 48 bits. But this is a general effect for all the Hop-by-Hop Options and Destination Options. AltMark does not add anything new in this sense.

I suspect that we are talking past each other, or that I'm missing something *very* fundamental here…

W

Best Regards,
Giuseppe
-----Original Message-----
From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]> Sent: Thursday, March 31, 2022 9:44 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-6man-ipv6-alt-mark-13.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Maintenance WG of the IETF.
Title : IPv6 Application of the Alternate Marking Method Authors : Giuseppe Fioccola
Tianran Zhou
Mauro Cociglio
Fengwei Qin
Ran Pang
Filename : draft-ietf-6man-ipv6-alt-mark-13.txt Pages : 23
Date : 2022-03-31
Abstract:
This document describes how the Alternate Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines a new Extension Header Option to encode Alternate Marking information in both the Hop-by-Hop Options Header and Destination Options Header.
The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6man-ipv6-alt-mark/
There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-6man-ipv6-alt-mark-13
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-ipv6-alt-mark-13
Internet-Drafts are also available by rsync at rsync.ietf.org<http://rsync.ietf.org/>::internet-drafts
-------------------------------------------------------------------- IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------