Subject: Warren Kumari's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 11 Aug 2021 14:21:47 -0700

Warren Kumari 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:
----------------------------------------------------------------------

I must be missing something fairly fundamental here.
"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.
   This is due to the specific set of requirements especially related to
   security, network management, policies and options supported which
   may vary between such limited domains.  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."

The above says that this must only be done in a limited/controlled domain, and
that operators are: "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.". The "only do this in
in limited domain" seems to simply punt on the security concerns /
considerations.

What is an operator supposed to do if their device doesn't understand this
option? Are you really suggesting that everyone needs to do though and update
edge firewall filters everywhere to block this? What happens when a filter is
unintentionally missed? Or when the device cannot filter N headers deep?

[edit firewall family inet6 filter altmark term demo]
[email-masked]# set from extension-header ?
Possible completions:
  <range>              Range of values
  [                    Open a set of values
  ah                   Authentication header
  any                  Any extension header
  dstopts              Destination options
  esp                  Encapsulating security payload
  fragment             Fragment
  hop-by-hop           Hop by hop options
  mobility             Mobility
  routing              Routing

Yes, many networks use automation to apply filters, but it is still
unreasonable to force operators to have to keep updating and deploying new
filters when new protocols are created.

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 12 Aug 2021 08:16:21 +0000

Hi Warren,
Thank you for your review. 
Please find my answers inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Warren Kumari via Datatracker <[email-masked]> 
Sent: Wednesday, August 11, 2021 11:22 PM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Warren Kumari's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with 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.)

The above says that this must only be done in a limited/controlled domain, and that operators are: "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.". The "only do this in in limited domain" seems to simply punt on the security concerns / considerations.

What is an operator supposed to do if their device doesn't understand this option? Are you really suggesting that everyone needs to do though and update edge firewall filters everywhere to block this? What happens when a filter is unintentionally missed? Or when the device cannot filter N headers deep?

[edit firewall family inet6 filter altmark term demo] [email-masked]# set from extension-header ?
Possible completions:
  <range>              Range of values
  [                    Open a set of values
  ah                   Authentication header
  any                  Any extension header
  dstopts              Destination options
  esp                  Encapsulating security payload
  fragment             Fragment
  hop-by-hop           Hop by hop options
  mobility             Mobility
  routing              Routing

Yes, many networks use automation to apply filters, but it is still unreasonable to force operators to have to keep updating and deploying new filters when new protocols are created.

[GF]: I'm not suggesting that everyone needs to update edge firewall filters. In the end, the kind of control is quite simple since the source node inserts the header if and only if the destination is within the controlled domain. I think this is a simple security check that, I guess, every operator already implements. Also note that there is some ongoing work in 6MAN to redefine HBH procedures in order to make HBH options more practical (e.g. https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/).

---

From: Warren Kumari <[email-masked]>
Date: Thu, 12 Aug 2021 10:10:29 -0400

On Thu, Aug 12, 2021 at 4:16 AM Giuseppe Fioccola <
[email-masked]> wrote:

> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> The above says that this must only be done in a limited/controlled domain,
> and that operators are: "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.". The
> "only do this in in limited domain" seems to simply punt on the security
> concerns / considerations.
>
> option? Are you really suggesting that everyone needs to do though and
> update edge firewall filters everywhere to block this? What happens when a
> filter is unintentionally missed? Or when the device cannot filter N
> headers deep?
>
> [GF]: I'm not suggesting that everyone needs to update edge firewall
> filters. In the end, the kind of control is quite simple since the source
> node inserts the header if and only if the destination is within the
> controlled domain.

The source node *should* only insert the header if the destination is
within the controlled domain, but that does not stop attackers from
generating them and trying to send them.

> I think this is a simple security check that, I guess, every operator
> already implements. Also note that there is some ongoing work in 6MAN to
> redefine HBH procedures in order to make HBH options more practical (e.g.
> https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/).
>
>
>
>

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra

---

From: Giuseppe Fioccola <[email-masked]>
Date: Thu, 12 Aug 2021 15:00:48 +0000

Dear Warren,
Please see inline with [GF].

Regards,

Giuseppe

From: Warren Kumari <[email-masked]>
Sent: Thursday, August 12, 2021 4:10 PM
To: Giuseppe Fioccola <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Warren Kumari's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS)

On Thu, Aug 12, 2021 at 4:16 AM Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>> wrote:
Hi Warren,
Thank you for your review.
Please find my answers inline tagged as [GF].

Regards,

Giuseppe

-----Original Message-----
From: Warren Kumari via Datatracker <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 11, 2021 11:22 PM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Warren Kumari's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS)

[edit firewall family inet6 filter altmark term demo] [email-masked]#<mailto:[email-masked]> set from extension-header ?
Possible completions:
  <range>              Range of values
  [                    Open a set of values
  ah                   Authentication header
  any                  Any extension header
  dstopts              Destination options
  esp                  Encapsulating security payload
  fragment             Fragment
  hop-by-hop           Hop by hop options
  mobility             Mobility
  routing              Routing

[GF]: I'm not suggesting that everyone needs to update edge firewall filters. In the end, the kind of control is quite simple since the source node inserts the header if and only if the destination is within the controlled domain.

The source node *should* only insert the header if the destination is within the controlled domain, but that does not stop attackers from generating them and trying to send them.

[GF]: In our draft the source node (e.g. CPE) is supposed to belong to the controlled domain, so, in theory, it can make sure that the destination is within the domain and can also filter packets from outside of the domain with inconsistent source, destination addresses and HbH. Regarding the possible attack within the domain, this can be mitigated under the assumption of controlled domain, which means that the network administrator must control the access to the network, making it a trusted domain.

I think this is a simple security check that, I guess, every operator already implements. Also note that there is some ongoing work in 6MAN to redefine HBH procedures in order to make HBH options more practical (e.g. https://datatracker.ietf.org/doc/draft-hinden-6man-hbh-processing/).

---

From: Warren Kumari <[email-masked]>
Date: Thu, 12 Aug 2021 11:12:20 -0400

On Thu, Aug 12, 2021 at 11:00 AM Giuseppe Fioccola <
[email-masked]> wrote:

> *From:* Warren Kumari <[email-masked]>
> *Sent:* Thursday, August 12, 2021 4:10 PM
> *To:* Giuseppe Fioccola <[email-masked]>
> *Cc:* The IESG <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: Warren Kumari's Discuss on
> draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS)
>
>
>
>
>
>
>
> [edit firewall family inet6 filter altmark term demo] [email-masked]#
> <[email-masked]> set from extension-header ?
> Possible completions:
>   <range>              Range of values
>   [                    Open a set of values
>   ah                   Authentication header
>   any                  Any extension header
> [GF]: In our draft the source node (e.g. CPE) is supposed to belong to the
> controlled domain,
>

Yes, I understand that the source node is **supposed** to belong to the
controlled domain, but my point is what happens when an attacker from
outside the domain starts sending packets with this option.

> so, in theory, it can make sure that the destination is within the domain
> and can also filter packets from outside of the domain with inconsistent
> source, destination addresses and HbH. Regarding the possible attack within
> the domain, this can be mitigated under the assumption of controlled
> domain, which means that the network administrator must control the access
> to the network, making it a trusted domain.
>

Again, you say: "Regarding the possible attack **within** the domain"
(emphasis added).

W

---

From: Giuseppe Fioccola <[email-masked]>
Date: Fri, 13 Aug 2021 09:01:57 +0000

Hi Warren,

Regards,

Giuseppe

Sent: Thursday, August 12, 2021 5:12 PM

On Thu, Aug 12, 2021 at 11:00 AM Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>> wrote:
Dear Warren,
Please see inline with [GF].

Regards,

Giuseppe

From: Warren Kumari <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 12, 2021 4:10 PM
To: Giuseppe Fioccola <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Warren Kumari's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS)

Regards,

Giuseppe

-----Original Message-----
From: Warren Kumari via Datatracker <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, August 11, 2021 11:22 PM
To: The IESG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Warren Kumari's Discuss on draft-ietf-6man-ipv6-alt-mark-08: (with DISCUSS)

[GF]: In our draft the source node (e.g. CPE) is supposed to belong to the controlled domain,

Yes, I understand that the source node is **supposed** to belong to the controlled domain, but my point is what happens when an attacker from outside the domain starts sending packets with this option.

so, in theory, it can make sure that the destination is within the domain and can also filter packets from outside of the domain with inconsistent source, destination addresses and HbH. Regarding the possible attack within the domain, this can be mitigated under the assumption of controlled domain, which means that the network administrator must control the access to the network, making it a trusted domain.

Again, you say: "Regarding the possible attack **within** the domain" (emphasis added).

[GF]: Sure. But I think that, if there is an attack within the domain, this is a bigger vulnerability for a network administrator and the attacker can do much more damage than affecting only the AltMark Options header.

W