Re: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt>

[Tom Herbert <[e-mail]>]

On Fri, Mar 30, 2018 at 7:51 AM, Joel M. Halpern <[e-mail]> wrote:
> I do not think this document is ready to be sent to the IETF and IESG for
> final approval.
> There are several kinds of problems.
>
> ECMP1: The document asserts that entropy information is put into the flow
> label.   I wish this worked.  I helped bring this idea forward years ago,
> independent of SRH.  Unfortunately, there are two related problems.  First,
> adoption appears to be low.  Second, and more important, there are reports
> from the field that doing thi actually breaks other things and cause packet
> re-ordering under some circumstances.  As a result, vendors are suggesting
> that people turn it off even when it is available.

Joel,

I assume you're referring to:

"If an array of layer-3 adjacencies is bound to the End.X SID, then
one entry of the array is selected based on a hash of the packet's
header (at least SA, DA, Flow Label)."

The problem with flow label isn't that it can cause OOO packets, it's
interaction with stateful techniques in intermediate nodes like
firewalls and load balancer that require all packets for a flow to
consistently hit the same stateful device. When the flow label changes
in mid flow, packets might be routed to a different device that
doesn't have the flow state and hence are dropped.

I imagine that one could argue that SRH is intended to be used in
closed domains so the operator could ensure there are no stateful
nodes present that would have an issue, but that makes correct
operation of the protocol conditional.

IMO the fix for the flow label/ECMP problem needs to include an update
to RFC6437 specifying 1) the flow label can only be set by the source,
nodes in the path MUST NOT set it, 2) if the flow label is set, it
MUST be an entropy identifier of the encapsulated transport flow so
that (SA, DA, flow label) is a good tuple representation of the flow,
3) the flow label MUST be the same for all packets sent on a flow
including fragments.

Tom

> ECMP2: If, with suitable analysis, we decide that this is actually safe to
> do, then the document needs to include both that analysis and clearly
> spelled out requirements that operators MUST verify that all their routers
> support this behavior and that they have enabled this behavior before
> turning on SRv6 usage.
>
> Structure: The text in section 2.3 says "It is assumed in this document that
> the SRH is added to the packet by its source".  This is at best
> disingenuous.  It is very clear that the value of this behavior lies
> primarily in use by the network, not by the packet sources.  Claiming
> otherwise results in a document with minimal utility.  Even this document
> itself disagrees with this assertion.  Tucked into the very next section is
> text saying that "outer header with an SRH applied to the incoming packet".
> If this behavior were a clearly spelled out requirement, rather than a
> "typically" and if the text in 2.3 were replaced with something realistic,
> then the document would at least be itnernally consistent and match the
> expected usages.
>
> Edge filtering: The text on edge filtering does not actually state that
> prevention of packets with SRH and a current DA of an internal node is
> mandatory.  Unless it is clearly stated, the security considerations text as
> currently written is significantly weakened.  If it is mandatory, then again
> the deployment section needs to note that an operator needs to verify that
> all of his edge devices support such filtering and have it properly enabled
> in order to use SRv6.
>
> Edge Filtering and hybrids: Other documents have talked about allowing
> external packets with SRv6 entries pointing to internal nodes (which means
> the DA upon arrival at the operator edge will be an internal node as I
> understand it).  It the intention is to permit that with appropriate
> security, then the edge filtering requirements need to be clear about the
> requirements for cryptographic validation at the edge.
>
> Yours,
> Joel
>
>
> On 3/29/18 4:30 PM, Bob Hinden wrote:
>>
>>
>> This message starts a two week 6MAN Working Group Last Call on advancing:
>>
>>         Title           : IPv6 Segment Routing Header (SRH)
>>         Authors         : Stefano Previdi
>>                           Clarence Filsfils
>>                           John Leddy
>>                           Satoru Matsushima
>>                           Daniel Voyer
>>         Filename       : draft-ietf-6man-segment-routing-header-11.txt
>>         Pages          : 34
>>         Date           : 2018-03-28
>>
>>       https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header
>>
>> as a Proposed Standard.  Substantive comments and statements of support
>> for publishing this document should be directed to the mailing list.
>> Editorial suggestions can be sent to the author.  This last call will
>> end on 12 April 2018.
>>
>> An issue tracker will be setup to track issues raised on this document.
>>
>> Thanks,
>> Bob & Ole
>>
>>
>>
>>
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------