Re: [ippm] Warren Kumari's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)

[Giuseppe Fioccola <[e-mail]>]

Hi Warren, 
Thanks for the review.
Please find my replies inline tagged as [GF].
Note that I plan to address your comments in the next version.

Best Regards,

Giuseppe

-----Original Message-----
From: Warren Kumari via Datatracker <[e-mail]> 
Sent: Wednesday, July 13, 2022 2:42 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Warren Kumari's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS)

Warren Kumari has entered the following ballot position for
draft-ietf-ippm-rfc8321bis-02: 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/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/



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

Section 7.1 says:
"The Alternate Marking Method is an example of a solution limited to a
controlled domain [RFC8799]. A controlled domain is a managed network that
selects, monitors, and controls access by enforcing policies at the domain
boundaries, in order to discard undesired external packets entering the domain
and check internal packets leaving the domain. [...] It must be possible to
control the domain boundaries, and use specific precautions if traffic
traverses the Internet."

"Controlled domain" isn't a magic incantation you invoke to make all security
issues disappear. Your definition of controlled domain sounds suspiciously like
"the network should magically stop bad packets, and evil people wanting to do
bad things!!!!".

RFC8799 does not define what makes a domain, nor how the boundary is protected.
Instead, it "it shows the need for a precise definition of "limited domain
membership" and for mechanisms to allow nodes to join a domain securely and to
find other members, including boundary nodes." and notes that "the Internet
does not have a well-defined concept of limited domains" and further that
"Domain boundaries that are defined administratively (e.g., by address
filtering rules in routers) are prone to leakage caused by human error,
especially if the limited domain traffic appears otherwise normal to the
boundary routers.  In this case, the network operator needs to take active
steps to protect the boundary."

The document states that "For security reasons, the Alternate Marking Method is
RECOMMENDED only for controlled domains." - but you have not defined how a
network operator is expected to define and enforce the domain boundary; simply
saying that the network should select, monitor, and control access by enforcing
policies at the domain boundaries, in order to discard undesired external
packets doesn't explain how the network should do this. How exactly does the
network know what packets are marked? How does the operator filter these? What
matching rule can be applied at the boundary to make sure that marked packets
do not enter or exit the network?

[GF]: I see your point. I think that, in draft-ietf-6man-ipv6-alt-mark we have a very detailed definition of "Controlled Domain" and I can include more details in RFC8321bis as well.
For example: 
"A controlled domain is a managed network where it is required to
   select, monitor and control the access to the network by enforcing
   policies at the domain boundaries in order to discard undesired
   external packets entering the domain and check the internal packets
   leaving the domain.  It does not necessarily mean that a controlled
   domain is a single administrative domain or a single organization.  A
   controlled domain can correspond to a single administrative domain or
   can be composed by multiple administrative domains under a defined
   network management.  Indeed, some scenarios may imply that the
   Alternate Marking Method involves more than one domain, but in these
   cases, it is RECOMMENDED that the multiple domains create a whole
   controlled domain while traversing the external domain by employing
   IPsec [RFC4301] authentication and encryption or other VPN technology
   that provides full packet confidentiality and integrity protection.
   In a few words, it must be possible to control the domain boundaries
   and eventually use specific precautions if the traffic traverse the
   Internet."

[GF]: I want to keep the definition general since the security concerns may change based on the specific protocol or extension where AltMark is applied.
In this regard, IOAM and AltMark are both on-path telemetry techniques and are both applied to controlled domain. But, looking at RFC9197, I see just the following definitions of Controlled Domain and terminology from 8799 seems used in a normative way. I can simply follow the example of RFC9197. Is it ok with you?

"IOAM is focused on "limited domains", as defined in [RFC8799].
      For IOAM, a limited domain could, for example, be an enterprise
      campus using physical connections between devices or an overlay
      network using virtual connections/tunnels for connectivity between
      said devices.  A limited domain that uses IOAM may constitute one
      or multiple "IOAM-Domains", each disambiguated through separate
      namespace identifiers.  An IOAM-Domain is bounded by its perimeter
      or edge.  IOAM-Domains may overlap inside the limited domain.
      Designers of protocol encapsulations for IOAM specify mechanisms
      to ensure that IOAM data stays within an IOAM-Domain.  In
      addition, the operator of such a domain is expected to put
      provisions in place to ensure that IOAM data does not leak beyond
      the edge of an IOAM-Domain using, for example, packet filtering
      methods.  The operator SHOULD consider the potential operational
      impact of IOAM to mechanisms, such as ECMP processing (e.g., load-
      balancing schemes based on packet length could be impacted by the
      increased packet size due to IOAM), PMTU (i.e., ensure that the
      MTU of all links within a domain is sufficiently large to support
      the increased packet size due to IOAM), and ICMP message handling
      (i.e., in case of IPv6, IOAM support for ICMPv6 echo request/reply
      is desired, which would translate into ICMPv6 extensions to enable
      IOAM-Data-Fields to be copied from an echo request message to an
      echo reply message)."
" Notably, IOAM is expected to be deployed in limited domains, thus
   confining the potential attack vectors to within the limited domain.
   A limited administrative domain provides the operator with the means
   to select, monitor, and control the access of all the network
   devices, making these devices trusted by the operator.  Indeed, in
   order to limit the scope of threats mentioned above to within the
   current limited domain, the network operator is expected to enforce
   policies that prevent IOAM traffic from leaking outside of the IOAM-
   Domain and prevent IOAM data from outside the domain to be processed
   and used within the domain."