Re: John Scudder's Discuss on draft-ietf-6man-ipv6-alt-mark-14: (with DISCUSS and COMMENT)

[John Scudder <[e-mail]>]

Hi Giuseppe,

I just started looking at version 15, and bumped into something I wanted to raise right away instead of waiting to complete my review of all the updates.

> On Jun 27, 2022, at 2:01 PM, Giuseppe Fioccola <[e-mail]> wrote:
> 
> 2. From what I understand of the rules about IPv6 extension header insertion
> (viz, only end nodes can do it), plus the assumptions stated in §2.1.1 about
> the extent of the "controlled domain", it would seem a natural consequence
> that ipv6-alt-mark is only applicable to networks where user traffic enters and
> exits a tunnel at the perimeter of the "controlled domain". I don't see this
> stated plainly anywhere in the document. If I'm correct this seems like an
> important characteristic to spell out. If I'm incorrect, I'd appreciate a
> discussion of where I went wrong.
> 
> [GF]: Yes, it is correct. This is a requirement based on the security concerns raised. I think we can highlight better this point in the Abstract and in the Introduction so it becomes clearer.

It looks like these are the lines you inserted to address this point:

In the Abstract,

                    According to RFC 8799, the IPv6 application of the
   Alternate Marking Method can be deployed in a controlled environment.

and in the Introduction:

   [RFC8799] discusses the use of the IPv6 Extension Headers as a
   typical limited domain solution.  Thus, the Alternate Marking Method
   MUST be applied to IPv6 only in a controlled environment, as further
   described in Section 2.1.  

I see two difficulties with this approach.

First, RFC 8799 is an Informational document published on the Independent Submission stream. Not only does it have no prima facie normative value because it’s Informative, it doesn’t even reflect IETF consensus; it is in short not an IETF document at all. So, while it may be interesting to read and if you want to refer the reader to it for specific points of information or elaboration, it’s not useful to refer to it as an authority, as you seem to be doing (“according to… can” and “thus” both suggest you’re relying on 8799 as a source of authority).

Second and more important, the new text doesn’t actually elucidate the point I had difficulty with while reading the document. To demonstrate something that might, I was thinking of something generally like this:

OLD:
   Therefore, the IPv6 application of the Alternate Marking Method MUST
   be deployed in a controlled domain.  It is RECOMMENDED that an
   implementation filters packets that carry Alternate Marking data and
   are entering or leaving the controlled domains.

NEW:
   The IPv6 application of the Alternate Marking Method MUST be deployed
   in a controlled domain. The consequence of this requirement is that
   it will typically only be applicable in an overlay network, that is,
   in the case where user traffic is encapsulated at one border of the
   domain and decapsulated at the other border, and the encapsulation
   includes the relevant extension header. The only exception would be
   if the user traffic originates and terminates within the controlled
   domain — but in practice this will not be common, see Section 2.1.1.

   An implementation MUST filter packets that carry Alternate Marking
   data and are entering or leaving the controlled domains.

That is just text I wrote off the top of my head as a guideline, you can use it, adapt it, or propose something different as you see fit. Then, if you also want to update your Abstract and Introduction, what I would have found helpful there is something like “the Alternate Marking Method will generally be deployed as part of an overlay network.” (But I don’t think this is required.)

By the way I also suggested changing SHOULD to MUST in the final sentence, because really, under what circumstances is it OK to *not* filter alt-mark at the borders and if you don’t, can you still call it a “controlled” domain? Indeed not mentioning this was an oversight in my earlier review.

Regards,

—John