Re: [spring] Is srv6 PSP a good idea

[Mark Smith <[e-mail]>]

Hi Darren,

On Fri, 28 Feb 2020 at 08:11, Darren Dukes (ddukes) <[e-mail]>
wrote:
>
> Mark AH is not defined for SRH.  There is no specification to ignore.
>

So AH is defined for RFC8200 IPv6 (and back to as early as RFC1883 IPv6 in
RFC1826), and if a node claims to talk RFC IPv6, then AH should be able to
be applied without issue because AH was designed to work with standard
RFC8200 IPv6.

This is why I think one perspective on AH is that it is a strict statement
on what is and isn't allowed to be performed on an IPv6 packet while it is
flight, because out-of-RFC8200 IPv6 specification operations will cause AH
checks to fail. I think AH is a effectively an RFC8200 processing
compliance checklist.

If SR is using IPv6 as IPv6 is specified, and as has been claimed and is
implied by using the term "IPv6" itself and referencing RFC8200, then SR
operations over IPv6 should never fail the integrity checks that AH
performs.

> Recall RFC8200 says nothing about mutability, it only describes things
that are
> modified in flight and how/why.
>
> RFC4301 builds on RFC8200 to define mutability for use in AH ICV
computation
> without having to modify RFC8200.  “Mutability" is not defined for IPv6
headers
> for any other reason.
>

Summing up these two paragraphs, I think this is saying that if an RFC
doesn't specifically prohibit something, then it would be fine to do it.

This would mean that no behaviour would be "out of spec".

Operationally I think that would be a disaster. I use RFCs as the authority
on how a device or implementation should be behaving. If a device or
implementation isn't behaving as the RFC it claims to comply with says, I
consider it a bug, and I lodge a fault with a vendor or implementer,
describing the non-compliant behaviour and referencing the RFC.

I can't then have a vendor or implementer dismiss my fault report with "we
comply with the specifications until we don't." because reporting bugs and
faults then serves no purpose.

It also means that RFCs with a goal of interoperability serves no purpose.

In the IETF that could be countered by having specifications that
enumerates and either permits or prohibits every conceivable operation,
including very perverse ones, that could be performed on a packet. It
wouldn't be surprising if RFCs became 10 times larger and took 10 times
longer to publish if we did that.


> draft-ietf-6man-semgnet-routing-header builds on RFC8200 to define a new
RH
> type without modifying RFC8200.
>
> draft-ietf-spring-srv6-network-programming builds on RFC8200 and
> draft-ietf-6man-segment-routing-header to define useful SIDs, their
behaviors
> and signaling within an SR domain without modifying any of the base
specifications.
>
> Of course RFC8200 has text covering the validity of extension header
insertion,
> deletion and processing at node(s) identified in the IPv6 destination
address (Section 4).
> As we all know, routing headers can’t work if a segment endpoint can’t
> process extension headers.
> Using this fact, PSP builds on RFC8200 to
> offer new functionality within an SR Domain.
>
> Of course RFC4301 says AH processing for new extension headers are
outside its
> scope, one can define AH processing for SRH with knowledge of, and
building on,
> all the above. Or they can just use ESP.
>

You can define new EHs and define read/write operations on their contents,
within the scope of what AH allows.

AH does not permit Next Header fields and the Payload Length field to be
modified, so removal and insertion of EHs is not permitted. In-flight
removal before the final end-DA, which is the node that performs AH
verification, will cause AH verification to fail.


Regards,
Mark.



> There is no ignoring here.
> There is conscious and careful building on existing standards as they are
written.
>
> Darren
>
>
> On Feb 26, 2020, at 6:57 AM, Mark Smith <[e-mail]> wrote:
>
>
>
> On Wed, 26 Feb 2020, 20:50 Xiejingrong (Jingrong), <[e-mail]>
wrote:
>>
>> Hi Mark,
>> I think both AH and PSP are optional.
>> If AH is desired to deploy, then the operator can choose not to use PSP.
>> If AH is not deployed, and the operator has its requirements of
incremental-deployment, then the operator can choose to use PSP.
>
>
> You've missed the point. AH is an assurance mechanism for something that
should *already* be happening - processing packets in accordance with RFC
8200.
>
> Somebody choosing not to use AH doesn't mean SPRING can ignore the IPv6
specifications.
>
>
>
>> If the already deployed PSP is removed from the draft, then I think it's
backward for interoperation.
>>
>> RFC4301:
>> 3.2.  How IPsec Works
>>
>>    IPsec uses two protocols to provide traffic security services --
>>    Authentication Header (AH) and Encapsulating Security Payload (ESP).
>>    Both protocols are described in detail in their respective RFCs
>>    [Ken05b, Ken05a].  IPsec implementations MUST support ESP and MAY
>>    support AH. (Support for AH has been downgraded to MAY because
>>    experience has shown that there are very few contexts in which ESP
>>    cannot provide the requisite security services.  Note that ESP can be
>>    used to provide only integrity, without confidentiality, making it
>>    comparable to AH in most contexts.)
>>
>>
>> Thanks,
>> Jingrong
>>
>> -----Original Message-----
>> From: spring [mailto:[e-mail]] On Behalf Of Mark Smith
>> Sent: Wednesday, February 26, 2020 8:31 AM
>> To: Pablo Camarillo (pcamaril) <[e-mail]>
>> Cc: Ron Bonica <[e-mail]>; [e-mail]; Joel M. Halpern <
[e-mail]>
>> Subject: Re: [spring] Is srv6 PSP a good idea
>>
>> Hi Pablo,
>>
>> On Sat, 21 Dec 2019 at 04:38, Pablo Camarillo (pcamaril) <
[e-mail]> wrote:
>> >
>> >  Hi Ron,
>> >
>> > I guess we are making some progress here but going in some circles. So
far we have moved from “this violates RFC8200” to “there are no use-cases
or benefits” to “this is complex for an ASIC” to “what is the benefit
again” and now back to “this is complex for an ASIC”.
>> >
>>
>> As far as I know, the next header field in both the IPv6 fixed header
and in extension headers is immutable while the packet is travelling within
the network, as is the payload length field in the IPv6 base fixed header.
>>
>> Nothing in RFC 8200 modifies those fields while the packet is in flight
between the packet's original source and final destination, nor is there
anything in RFC 8200 that specifies how to do those modifications and any
other discussion about the consequences and considerations when doing so.
>>
>>
>> The IPsec AH header is providing integrity checking over fields in the
>> IPv6 packet that shouldn't be being modified while the packet is within
the network. What is and isn't protected by AH can be seen to be a
specification of what processing on a packet can and cannot occur while it
is in flight across the network towards its final destination.
>>
>> Therefore, AH is really a quality assurance mechanism for the network
packet processing that RFC 8200 specifies. The processing of the packet by
the network with or without the use of AH should be the same. AH should
really only be necessary if there is a belief that the network is likely
not to be processing packets in accordance to RFC 8200, either accidentally
or intentionally.
>>
>>
>> Per RFC4302 (IPsec AH),  the following section explicitly states which
fields in the IPv6 header are immutable and are to be protected by AH:
>>
>>
>> 3.3.3.1.2.  ICV Computation for IPv6
>>
>> 3.3.3.1.2.1.  Base Header Fields
>>
>>    The IPv6 base header fields are classified as follows:
>>
>> Immutable
>>            Version
>>            Payload Length
>>            Next Header
>>            Source Address
>>            Destination Address (without Routing Extension Header)
>>
>>    Mutable but predictable
>>            Destination Address (with Routing Extension Header)
>>
>>    Mutable (zeroed prior to ICV calculation)
>>            DSCP (6 bits, see RFC2474 [NBBB98])
>>            ECN (2 bits, see RFC3168 [RFB01])
>>            Flow Label (*)
>>            Hop Limit
>>
>>         (*) The flow label described in AHv1 was mutable, and in
>>             RFC 2460 [DH98] was potentially mutable.  To retain
>>             compatibility with existing AH implementations, the
>>             flow label is not included in the ICV in AHv2.
>>
>>
>>
>>
>> > As for how easy or not something is, the PSP behavior has been
implemented and deployed (running code). The use-cases have been described
and positively reinforced by operators. I don't think there is any further
explanation to provide.
>> >
>>
>> "Just because you can do something, doesn't mean you should."
>>
>> How much troubleshooting experience have they had with this?
>>
>> I think a very important factor is how easy something is to troubleshoot
- how obvious is the mechanism works; is the mechanism consistent with
existing behaviours i.e. the principle of least surprise (removing EHs at
an intermediary hop certainly isn't in IPv6, even if the intermediary hop
as the packet's current DA); when it inevitably fails, how obvious is it
where the fault is likely to be; and how quickly can a typical fault be
rectified.
>>
>>
>>
>> Regards,
>> Mark.
>>
>>
>>
>>
>> > Happy Holidays,
>> > Pablo.
>> >
>> >
>> > -----Original Message-----
>> > From: Ron Bonica <[e-mail]>
>> > Date: Tuesday, 17 December 2019 at 16:06
>> > To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "Joel M.
>> > Halpern" <[e-mail]>, "[e-mail]" <[e-mail]>
>> > Subject: RE: [spring] Is srv6 PSP a good idea
>> >
>> >     Pablo,
>> >
>> >     In your message below, are you arguing that it is easier for the
penultimate node to remove the SRH than it is for the ultimate node to
ignore it? I think that would be a stretch.
>> >
>> >

>> > Ron
>> >
>> >
>> >
>> >     Juniper Business Use Only
>> >
>> >     -----Original Message-----
>> >     From: Pablo Camarillo (pcamaril) <[e-mail]>
>> >     Sent: Saturday, December 14, 2019 4:50 AM
>> >     To: Ron Bonica <[e-mail]>; Joel M. Halpern <
[e-mail]>; [e-mail]
>> >     Subject: Re: [spring] Is srv6 PSP a good idea
>> >
>> >     Ron,
>> >
>> >     What is the "price paid by the penultimate segment"? All the
current implementations do this at linerate with no performance degradation
as I have explained in my email before.
>> >
>> >     There is substantial benefit. Four operators have deployed PSP,
which proves the benefit.
>> >     It enables new use-cases that have been provided by other members
in the list. [1], [2] and [5].
>> >     From operational perspective it is not complex as explained in [3].
>> >     Operators have expressed their value in [4] and [5]..
>> >
>> >     [1].-
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/wTLJQkzC6xwSNPbhB84VH0mLXx0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcdXeBzk_$
>> >     [2].-
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/V0ZpjVLSVZxHaBwecXFxqJjlg_c__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcU9bihBc$
>> >     [3].-
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/ssobwemrPz0uEZjvRCZP1e4l_l0__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4Icc_wo902$
>> >     [4].-
https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spring/KXCBHT8Tpy17S5BsJXLBS35yZbk__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiBzoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IcRXo_q-1$
>> >     [5].-
>> > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/spri
>> > ng/ErcErN39RIlzkL5SKNVAeEWpnAI__;!!NEt6yMaO-gk!TzJ8_ZyDvWvLPNwsalQ6RiB
>> > zoLkP6Vj30eGaDVFEWdDq_IdPkWwaIL4IceGPpSab$
>> >
>> >     Cheers,
>> >     Pablo.
>> >
>> >     -----Original Message-----
>> >     From: Ron Bonica <[e-mail]>
>> >     Date: Thursday, 12 December 2019 at 21:50
>> >     To: "Pablo Camarillo (pcamaril)" <[e-mail]>, "Joel M.
Halpern" <[e-mail]>, "[e-mail]" <[e-mail]>
>> >     Subject: RE: [spring] Is srv6 PSP a good idea
>> >
>> >         Pablo,
>> >
>> >         I am not convinced the benefit derived by the ultimate segment
>> > justifies the price paid by the penultimate segment. Specifically,
>> >
>> >         - the ultimate segment benefits because it doesn't have to
skip over the SRH with SL == 0
>> >         - in order for the ultimate segment to derive this benefit,
>> > the penultimate segment needs to remove bytes from the middle of the
>> > packet and update two fields in the IPv6 header
>> >
>> >         As Joel said, we typically don't add options (i.e.,
complexity) to a specification unless there is substantial benefit.
>> >
>> >                                                             Ron
>> >
>> >
>> >
>> >
>> >         Juniper Business Use Only
>> >
>> >         -----Original Message-----
>> >         From: spring <[e-mail]> On Behalf Of Pablo
Camarillo (pcamaril)
>> >         Sent: Wednesday, December 11, 2019 3:12 PM
>> >         To: Joel M. Halpern <[e-mail]>; [e-mail]
>> >         Subject: Re: [spring] Is srv6 PSP a good idea
>> >
>> >         Joel,
>> >
>> >         1.- The use-case for PSP has already been provided at the
mailer. There are scenarios where it provides benefits to operators.
>> >
>> >         2.- The PSP behavior is optional. It is up to the operator in
his deployment to decide whether to enable it or not at one particular
router.
>> >         Similarly, a vendor may decide not to implement it. The PSP
behavior has been implemented by several vendors and deployed (see the srv6
deployment draft).
>> >
>> >         3.- A network may have PSP enabled at some nodes and not at
others.  Everything is still interoperable and works fine.
>> >
>> >         4.- PSP is not a complex operation in hardware (doable at
linerate on existing merchant silicon).
>> >         Example: It has been implemented and deployed on Broadcom
J/J+. If I recall correctly Broadcom Jericho+ started shipping in March
2016! PSP is supported on this platform at linerate with no performance
degradation (neither PPPS nor BW).
>> >         Given that this is doable in a platform from more than 3 years
ago, I fail to see how you need "very special provision" to do this.
>> >
>> >         Is it really something that horrible to provide freedom of
choice to the operators deploying?
>> >
>> >         In summary, it can be implemented without any burden in
hardware and deployment experience prove this is beneficial to operators.
>> >
>> >         Thanks,
>> >         Pablo.
>> >
>> >         -----Original Message-----
>> >         From: spring <[e-mail]> on behalf of "Joel M.
Halpern" <[e-mail]>
>> >         Date: Wednesday, 11 December 2019 at 03:55
>> >         To: "[e-mail]" <[e-mail]>
>> >         Subject: [spring] Is srv6 PSP a good idea
>> >
>> >             For purposes of this thread, even if you think PSP
violates RFC 8200,
>> >             let us assume that it is legal.
>> >
>> >             As I understand it, the PSP situation is:
>> >             o the packet arrives at the place (let's not argue about
whether SIDs
>> >             are locators) identified by the SID in the destination
address field
>> >             o that SID is the next to last SID in the SID list
>> >             o that sid is marked as / known to be PSP
>> >             o at the intended place in the processing pseudocode, the
last (first)
>> >             entry in the SRH is copied into the destination IPv6
address field of
>> >             the packet
>> >             -> The SRH being used is then removed from the packet.
>> >
>> >             In order to evaluate whether this is a good idea, we have
to have some
>> >             idea of the benefit.  It may be that I am missing some of
the benefit,
>> >             and I would appreciate clarification.
>> >             As far as I can tell, the benefit of this removal is that
in exchange
>> >             for this node doing the work of removing the SRH, the
final node in the
>> >             SRH does not have to process the SRH at all, as it has
been removed.
>> >
>> >             I have trouble seeing how that work tradeoff can be
beneficial.
>> >             Removing bytes from the middle of a packet is a complex
operation.
>> >             Doing so in Silicon (we expect this to be done in the fast
path of
>> >             significant forwarders as I understand it) requires very
special
>> >             provision.  Even in software, removing bytes from the
middle of a packet
>> >             requires somewhere between some and a lot of extra work.
It is
>> >             distinctly NOT free.
>> >
>> >             In contrast, we have assumed that the work of processing
SRH itself is
>> >             tractable, since otherwise all of SRv6 would be
problematic.  So why is
>> >             this necessary.
>> >
>> >             Yours,
>> >             Joel
>> >
>> >             PS: Note that both the MPLS case and the encapsulation
case are very
>> >             different in that the material being removed is at the
front of the IP
>> >             packet.  Pop or prepend are MUCH easier than
middle-removal (or
>> >             middle-insertion).
>> >
>> >             _______________________________________________
>> >             spring mailing list
>> >             [e-mail]
>> >
>> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
>> > ng__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r7
>> > 8vsFpWAHa8hW2$
>> >
>> >
>> >         _______________________________________________
>> >         spring mailing list
>> >         [e-mail]
>> >
>> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spri
>> > ng__;!!NEt6yMaO-gk!Uvd5DRUIJlsmob5a7r4JRgMMbZcE60JOPIW3K2MubKpIuKXA1r7
>> > 8vsFpWAHa8hW2$
>> >
>> >
>> >
>> > _______________________________________________
>> > spring mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/spring
>>
>> _______________________________________________
>> spring mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring
>
>