Subject: Re: [spring] Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2020 04:10:31 -0300

Pablo & IESG,

May I ask why, if you are going against RFC8754, you do it in this 
documents as opposed to formally update RFC8754?

Put another way: what was the point of 6man (and eventually the IETF) of 
standardizing RFC8754 if then this document is going to change the spec 
without formally updating it?

Thanks,
Fernando

On 30/9/20 10:18, Pablo Camarillo (pcamaril) wrote:
[....]
> ...
>> (1b) It would be nice if the behavior in §4.1.1 were also
>> specified using pseudocode. As written, I am not sure if the intent
>> is to process any upper-layer header or only specific ones. Is the
>> objective for this operation to be similar to the one in
>> §4.3.1.2/rfc8754? Please be specific on what is meant by "allowed
>> by local configuration".
>> 
> [PC] Yes, we can structure the text in 4.1.1 in pseudocode form. The
> [PC] processing is not the same as RFC8754/Section 4.3.1.2. The
> “allowed by [PC] local configuration” is to enable the processing of
> only specific types [PC] of Upper-layer Headers for packets addressed
> to an SRv6 SID of the [PC] specific behaviors. E.g. An operator may
> not wish to have BGP sessions [PC] (or in general any TCP traffic)
> destined to a local SID, but may want to [PC] enable ICMPv6 packet
> processing for OAM purposes.
[....]

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2020 05:58:24 -0300

On 23/9/20 21:22, Erik Kline wrote:
>     (5) This point is for the IESG to discuss.
> 
>     §4.16.1.2 <http://4.16.1.2>:
> 
>            The End, End.X and End.T behaviors with PSP do not contravene
>            Section 4 of [RFC8200] because the destination address of the
>            incoming packet is the address of the node executing the
>     behavior.
> 
>     The spring WG's interpretation of rfc8200 was a central point in the
>     appeal
>     presented against the WG consensus on this document.  The text above, I
>     believe, reflects that consensus.
> 
>     However, given that the document relies on the spring WG's
>     interpretation of
>     rfc8200, I think it would be better if the text is explicit.
> 
>     Suggestion: to add at the end of the paragraph>
> 
>         This conclusion represents the consensus interpretation of the
>     spring WG.
> 
> 
> This seems like an important -- and entirely reasonable -- thing to note.

FWIW, one would expect that, if anything, if a matter is subject to 
interpretation, it would be for the group that published the spec or the 
IETF as a whole to discuss the topic.

I did my share of reading on how the text in RFC8200 ended up being what 
it currently is and, if anything, one may say the text is far from 
perfect -- but the interpretation that this document is making seems to 
go against the IPv6 architecture, and even contradict the text from 
previous revisions of the IPv6 specification (before we made the 
relevant text sloppy in RFC8200).

Namely:

IPv6 has always forbidden en-route insertion and removal of IPv6 EHs. 
RFC2460 contains this text (very similar to what's in its predecessor 
RFC1883):

    With one exception, extension headers are not examined or processed
    by any node along a packet's delivery path, until the packet reaches
    the node (or each of the set of nodes, in the case of multicast)
    identified in the Destination Address field of the IPv6 header.
    There, normal demultiplexing on the Next Header field of the IPv6
    header invokes the module to process the first extension header, or
    the upper-layer header if no extension header is present.  The
    contents and semantics of each extension header determine whether or
    not to proceed to the next header.
  [....]
    The exception referred to in the preceding paragraph is the Hop-by-
    Hop Options header, which carries information that must be examined
    and processed by every node along a packet's delivery path, including
    the source and destination nodes.

The text highlights that HBH options are processed by every node on the 
path, and that other EHs are only processed when the packet reaches the 
address in the "Destination Address" field. Indeed, RHs are processed 
when the packets get to such destination address, and other EHs and 
upper layer protocols are processed when the packet reaches the 
Destination Address. For packets that employ a RH, these later EHs and 
upper layer protocols will get processed by the node(s) identified in 
the Destination Address when Segments Left==0 -- that is, by the final 
destination.

In the same timeframe that the rfc2460bis effort (that eventually lead 
to RFC8200) was being pursued, an individual internet-draft 
(draft-previdi-6man-segment-routing-header) was proposing to perform 
en-route header insertion/removal. When this later draft appeared in the 
radar of 6man participants, there were many objections to such proposal, 
as it was violating existing standards.

The proponents of draft-previdi-6man-segment-routing-header argued that 
RFC2460 didn't explicitly forbid en-route EH-insertion/removal, and 
hence their proposal was not violating any specifications. Some of them 
claimed that the use of the term "processing" was ambiguous.

While it was clear to the vast majority of the 6man wg that the IPv6 
architecture and the ipv6 specification didn't allow for EH 
insertion/removal, participants felt that, since the rfc2460bis effort 
was ongoing, rfc2460bis should take the chance to be crystal clear on 
this point, to avoid possible future claims that such behavior was allowed.

While the document was still in the 6man wg, the proponents of 
draft-previdi-6man-segment-routing-header resisted any clarifications in 
this respect (please see 
<https://mailarchive.ietf.org/arch/msg/ietf/j1O11x4ICMUWGJmzlJfCx0y0-c8/>), 
and hence 6man shippoed for publication a version of the document that 
didn't spell out the prohibition of en-route EH insertion/removal.

During the IETF LC for the document, there was a strong push to have 
rfc2460bis be explicit about the prohibition of en-route 
insertion/removal of extension headers, and some subset of the 
participants crafted the text that eventually made it into RFC8200. 
Essentially, they spelled out all the prohibited actions, as explicitly 
sa possible, and added them along the existing text. The resulting text was:

    Extension headers (except for the Hop-by-Hop Options header) are not
    processed, inserted, or deleted by any node along a packet's delivery
    path, until the packet reaches the node (or each of the set of nodes,
    in the case of multicast) identified in the Destination Address field
    of the IPv6 header.

While the intent was to be more explicit about the things that were 
prohibited, the addition of these extra terms alongside the existing 
text ended up introducing a bug in the specification since, as crafted, 
the text suggests that nodes that get to process EHs also get to e.g. 
insert and remove EHs.  This is why I consider this a bug, and why I've 
submitted Erratum 6003 on RFC8200.

RFC8200 contains, in Appendix B, a summary of the changes from RFC2460, 
and notes that:

    o  Clarified that extension headers (except for the Hop-by-Hop
       Options header) are not processed, inserted, or deleted by any
       node along a packet's delivery path.

This spells out the intent of the corresponding text. 
draft-ietf-6man-rfc2460bis-13 (the last internet-draft version of 
RFC8200), it spells out the intent of the specification with even more 
detail:

       01)  Added text that Extension headers must never be inserted by
            any node other than the source of the packet.

Finally, draft-ietf-6man-rfc2460bis-08, the document that was shipped by 
the 6man wg to the IESG for publication, was indeed very explicit about 
the serious problems with en-route insertion/removal of EHs:

    The insertion of Extension Headers by any node other than the source
    of the packet causes serious problems.  Two examples include breaking
    the integrity checks provided by the Authentication Header Integrity
    [RFC4302], and breaking Path MTU Discovery which can result in ICMP
    error messages being sent to the source of the packet that did not
    insert the header, rather than the node that inserted the header.

This very same problems are caused when the node inserting or removing 
EHs is a node listed in an RH.

It is also worth noting that RFC8200 elevated the status of IPv6 to 
"Internet Standard". Since RFC2460 by no means allows for en-route 
header insertion/removal/deletion, the incorporation of this "feature" 
in RFC8200 would have prevented the elevation of IPv6 to Internet 
Standard. This is yet another indication that Erratum 6003 refers to a 
bug in the specification, as opposed to an intended protocol behavior 
that would be a change from the preceding revision of the standard, RFC2460.

As per the above, it would seem to me that before a Spring documents 
makes any arbitrary interpretation of RFC8200 that happens to represent 
a change to the IPv6 Architecture, 6man should clarify the topic, and if 
the IPv6 architecture is to be changed, the IETF as a whole should be 
involved (since that would probably be even out of the scope of 6man).

Thanks,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 1 Oct 2020 14:53:31 -0400

First, there is a lot of disagreement and vagueness about when one 
should mark an RFC as "updating" another RFC.  So it would be hard for 
me to claim that you are wrong.  But it would also be hard to claim that 
what you propose is necessary.

In this particular case, my reading as shepherd is that the changes 
relative to 8754 apply only when this document is being implemented.  If 
one is not implementing the behaviors in this document, one does not 
need to worry about it when implementing 8754.  Based on that and my 
understanding of "updates", I would not expect this document to assert 
that it updates 8754.

Yours,
joel

---

From: Fernando Gont <[email-masked]>
Date: Thu, 1 Oct 2020 22:18:37 -0300

Hello, Joel,

If this document is specifying a behavior that deviates from RFC8754, 
then it's hard for me to understand why this document should not be 
updating RFC8754.

Otherwise, it essentially means that one can violate an existing 
specification at will by simply packing the new behavior with other 
things that comply with the spec.

One would expect that the behavior of a protocol can be explained and 
understood by reading the core spec and all updating documents.

This document not only seems to go outside of Springs charter, but also 
seems to be updating a bunch of core implications "under the hood", 
creating not only an specification mess, but also a very bad precedent.

RFC8754 is one example. The this document also specifies behavior (PSP) 
for nodes that fail to comply with a core spec (RFC8200) on which this 
document is based. And the same is true for other core documents.

This seems to me like setting a really bad precendent.

Thanks,
Fernando

On 1/10/20 15:53, Joel M. Halpern wrote:
>> Put another way: what was the point of 6man (and eventually the IETF) 
>> of standardizing RFC8754 if then this document is going to change the 
>> spec without formally updating it?
>>
>> Thanks,
>> Fernando
>>
>>
>>
>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 1 Oct 2020 22:56:22 -0400

With regard to the 8200 issue, I consider that I am bound by the IESG 
decision on your appeal.  I understand you disagree with their 
conclusion.  That is between you and them.

With regard to the issue of behavioral change, 8754 is explicit that 
other documents can define other behaviors.  That does not change the 
behaviors defined in 8754.  As such, I am having trouble following your 
reasoning as to why the network programming draft changes 8754.  The NP 
draft does not change the processing rules for the behaviors defined in 
8754.
When one combines that apparent separation with the lack of specificity 
or community agreement on how to clarify "updates" tags, I do not see 
how you can insist that NP needs to be marked as updating 8754.  If the 
IESG decides that they think it should be marked as updating, then we 
will so mark it.

Yours,
Joel

On 10/1/2020 9:18 PM, Fernando Gont wrote:
>> me to claim that you are wrong.  But it would also be hard to claim 
>> that what you propose is necessary.
>>
>> relative to 8754 apply only when this document is being implemented.  
>> If one is not implementing the behaviors in this document, one does 
>> not need to worry about it when implementing 8754.  Based on that and 
>> my understanding of "updates", I would not expect this document to 
>> assert that it updates 8754.
>>
>> Yours,
>> joel
>>

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 7 Oct 2020 17:04:11 +0200

On September 30, 2020 at 9:18:37 AM, Pablo Camarillo wrote:

Pablo:

Hi!

Just leaving below the points I still want to talk about.

Thanks!

Alvaro.

...
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
...
> > (1b) It would be nice if the behavior in §4.1.1 were also specified
> > using pseudocode...
...
> §4.1.1 is called from different places, while processing different
> behaviors. Is it expected that the "local configuration" will cover each
> behavior individually, or will the operator be able to configure a single
> policy for all? In either case, it would be good to mention it.
>
[PC2] In the document we've left 'local configuration' up to an
[PC2] implementation. Whether an implementation implements the local
[PC2] configuration on an interface as an ACL or globally for all SIDs or per
[PC2] SID via some API is not for this document to decide, and has no impact
[PC2] on interoperability.

True, it has no impact on interoperability, but it can have an impact
on the operation of the network.  While not including details about
local configuration, I would like to see some guidance on the
definition of proper policies.  For example, considering your example
of allowing ICMPv6, OAM may be important, but forwarding a packet that
is not in line with the behavior would not be.

Along those lines, the headend policy should be consistent with the
behavior and any local configuration.  This expectation should also be
mentioned somewhere.

...
> > (3) The description of the flavors in §4.16 is also unclear.
> ...
> For an endpoint behavior that indicates more than one flavor, which one
> should be applied?
>
> For some of the behaviors, 29 (End with PSP&USD) for example, the flavor
> used seems to depend on the number of SLs: if received with SL == 0, then
> the flavor is USD, but if received with SL == 1 then use PSP. But for other
> behaviors, 30 (End with USP&USD) for example, which flavor should be applied
> if both are supported?
>
[PC2] When a behavior (e.g. End) is combined with one or more flavors (e.g.
[PC2] USP & USD), their combined pseudocode is what determines the packet
[PC2] processing. In the specific example of USP&USD (when SL=0), the
[PC2] pseudocode would end up first removing the processed SRH and then,
[PC2] depending on the next upper-layer header, also removing the outer IPv6
[PC2] encapsulation header if/when there is an inner IP packet.

Oh, it's the combination; that is not mentioned anywhere.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 7 Oct 2020 11:15:58 -0400

Alvaro, at this point as document shepherd I have to ask if these are 
still discuss level concerns?

Yours,
Joel

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 7 Oct 2020 16:08:22 +0000

Hi Alvaro,

Many thanks for the feedback. Inline below with PC3.
Note that we have just posted rev24 as per the comments below.

Cheers,
Pablo.

-----Original Message-----
From: Alvaro Retana <[email-masked]> 
Sent: miércoles, 7 de octubre de 2020 17:04
To: The IESG <[email-masked]>; Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; Bruno Decraene <[email-masked]>; [email-masked]; Joel Halpern <[email-masked]>; [email-masked]
Subject: RE: Alvaro Retana's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

Pablo:

Hi!

Thanks!

Alvaro.

...
...
...
> behaviors. Is it expected that the "local configuration" will cover 
> each behavior individually, or will the operator be able to configure 
> a single policy for all? In either case, it would be good to mention it.
>
[PC2] In the document we've left 'local configuration' up to an [PC2] implementation. Whether an implementation implements the local [PC2] configuration on an interface as an ACL or globally for all SIDs or per [PC2] SID via some API is not for this document to decide, and has no impact [PC2] on interoperability.

True, it has no impact on interoperability, but it can have an impact on the operation of the network.  While not including details about local configuration, I would like to see some guidance on the definition of proper policies.  For example, considering your example of allowing ICMPv6, OAM may be important, but forwarding a packet that is not in line with the behavior would not be.
[PC3] Indeed, it's a good point. We have posted in rev24 the following diff: 
<OLD>
   Notes:
   S01.  As an example, an operator may not wish to have any TCP traffic
   destined to a local SID, but may want to enable ICMPv6 packet
   processing for OAM purposes.
</OLD>
<NEW>
   Allowing processing of specific Upper-Layer Headers types is useful
   for OAM.  As an example, an operator might permit pinging of SIDs.
   To do this they may enable local configuration to allow Upper-layer
   Header type 58 (ICMPv6).

   It is RECOMMENDED that an implementation of local configuration only
   allows Upper-layer Header processing of types that do not result in
   the packet being forwarded (e.g.  ICMPv6).
</NEW>

Along those lines, the headend policy should be consistent with the behavior and any local configuration.  This expectation should also be mentioned somewhere.
[PC3] Indeed. We've included that in the Security Considerations section.
<OLD>
   This document introduces SRv6 Endpoint and SR Policy Headend
   behaviors for implementation on SRv6 capable nodes in the network.
   As such, this document does not introduce any new
   security considerations.
</OLD>
<NEW (third line)>
   This document introduces SRv6 Endpoint and SR Policy Headend
   behaviors for implementation on SRv6 capable nodes in the network.
   The headend policy definition should be consistent with the specific
   behavior used and any local configuration (as specified in
   Section 4.1.1).  As such, this document does not introduce any new
   security considerations.
</NEW>

...
> For an endpoint behavior that indicates more than one flavor, which 
> one should be applied?
>
> For some of the behaviors, 29 (End with PSP&USD) for example, the 
> flavor used seems to depend on the number of SLs: if received with SL 
> == 0, then the flavor is USD, but if received with SL == 1 then use 
> PSP. But for other behaviors, 30 (End with USP&USD) for example, which 
> flavor should be applied if both are supported?
>
[PC2] When a behavior (e.g. End) is combined with one or more flavors (e.g.
[PC2] USP & USD), their combined pseudocode is what determines the packet [PC2] processing. In the specific example of USP&USD (when SL=0), the [PC2] pseudocode would end up first removing the processed SRH and then, [PC2] depending on the next upper-layer header, also removing the outer IPv6 [PC2] encapsulation header if/when there is an inner IP packet.

Oh, it's the combination; that is not mentioned anywhere.
[PC3] Currently we have the following text present in 4.16. 
> The End, End.X and End.T behaviors can support these flavors either individually or in combinations. 

Thank you for your time!

---

From: Alvaro Retana <[email-masked]>
Date: Wed, 7 Oct 2020 18:09:56 +0200

Thanks Pablo!

I’m clearing my DISCUSS.

Alvaro.

On October 7, 2020 at 12:08:27 PM, Pablo Camarillo (pcamaril) (
[email-masked]) wrote: