Subject: Processing the Routing Extension Headers ( was: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt )

From: Ron Bonica <[email-masked]>
Date: Tue, 17 Apr 2018 14:29:45 +0000

Folks,

There are two models for processing the Routing Extension headers. The first model is exemplified by. The second is exemplified by the SRH.

The RHO model is more computationally expensive than the SRH model, but it reduces the size of the Routing Extension header by 16 bytes. The SRH model is less computationally expensive than the RH0 model, but it increases the size of the Routing Extension header by 16 bytes.

Given that:

- Forwarding ASICs are fast and getting faster
- Routing Extension headers tend to be very long

I recommend that SRv6 optimizes for Routing Extension header length and leverages the processing model exemplified by the RH0.

In the examples below, a packet is routed from S to D, visiting I1, I2 and I3 along the way. The first example demonstrates how RH0 routes the packet. In this example, the Routing Extension Header is 50 bytes long. The second example demonstrates how SRH routes the same packet.  In this example, the routing Extension header is 66 bytes long.

                                                                          Ron

RH0 example (Copied from RFC 2460)
---------------------------------------------------
As the packet travels from S to I1:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I1            Segments Left = 3
                                            Address[1] = I2
                                            Address[2] = I3
                                            Address[3] = D

   As the packet travels from I1 to I2:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I2            Segments Left = 2
                                            Address[1] = I1
                                            Address[2] = I3
                                            Address[3] = D

   As the packet travels from I2 to I3:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = I3            Segments Left = 1
                                            Address[1] = I1
                                            Address[2] = I2
                                            Address[3] = D

   As the packet travels from I3 to D:

        Source Address = S                  Hdr Ext Len = 6
        Destination Address = D             Segments Left = 0
                                            Address[1] = I1
                                            Address[2] = I2
                                            Address[3] = I3

SRH Example (Copied from Darren's previous email and correcting Hdr Ext Len)
----------------------------------------------------------------------

As the packet travels from S to I1:

       Source Address = S                  Hdr Ext Len = 8
       Destination Address = I1            Segments Left = 3

                                           Segment List[0] = D
                                           Segment List[1] = I3
                                           Segment List[2] = I2
                                           Segment List[3] = I1

  As the packet travels from I1 to I2:

       Source Address = S                  Hdr Ext Len = 8
       Destination Address = I2            Segments Left = 2

                                           Segment List[0] = D
                                           Segment List[1] = I3
                                           Segment List[2] = I2
                                           Segment List[3] = I1

 As the packet travels from I2 to I3:

       Source Address = S                  Hdr Ext Len = 8
       Destination Address = I3            Segments Left = 1

                                           Segment List[0] = D
                                           Segment List[1] = I3
                                           Segment List[2] = I2
                                           Segment List[3] = I1

  As the packet travels from I3 to D:

       Source Address = S                  Hdr Ext Len = 8
       Destination Address = D             Segments Left = 0

                                           Segment List[0] = D
                                           Segment List[1] = I3
                                           Segment List[2] = I2
                                           Segment List[3] = I1

---

From: "Leddy, John" <[email-masked]>
Date: Tue, 17 Apr 2018 15:18:21 +0000

Ron,

Doesn't what you are proposing cause problems if there is a HMAC TLV?
Trying to "fix" the header to be what the source had originally set in order to verify the HMAC seems a little convoluted.

John

On 4/17/18, 10:30 AM, "ipv6 on behalf of Ron Bonica" <[email-masked] on behalf of [email-masked]> wrote:

    Folks,

    
    Given that:

    
    
                                                                              Ron

    

    

    

    
                                               Segment List[0] = D
                                               Segment List[1] = I3
                                               Segment List[2] = I2
                                               Segment List[3] = I1

    
                                               Segment List[0] = D
                                               Segment List[1] = I3
                                               Segment List[2] = I2
                                               Segment List[3] = I1

    
                                               Segment List[0] = D
                                               Segment List[1] = I3
                                               Segment List[2] = I2
                                               Segment List[3] = I1

    
                                               Segment List[0] = D
                                               Segment List[1] = I3
                                               Segment List[2] = I2
                                               Segment List[3] = I1
    
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    [email-masked]
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Wed, 18 Apr 2018 06:12:56 +1000

Hi Ron,

On 18 April 2018 at 00:29, Ron Bonica <[email-masked]> wrote:

> Folks,
>
> There are two models for processing the Routing Extension headers. The
> first model is exemplified by. The second is exemplified by the SRH.
>
> The RHO model is more computationally expensive than the SRH model, but it
> reduces the size of the Routing Extension header by 16 bytes. The SRH model
> is less computationally expensive than the RH0 model, but it increases the
> size of the Routing Extension header by 16 bytes.
>

So I'm wondering if SR really needs 128 bit Segment Identifiers (i.e. IPv6
addresses as SIDs)? If 20 bits are enough in an MPLS network, is 20 bits
enough in an IPv6 network?

I can understand trying to use SIDs that are directly usable in the
forwarding plane, however the resulting overhead size of using IPv6
addresses as 128 bit SIDs seems to be causing lots of issues.

I think a simple mapping scheme between big enough SIDs and IPv6 addresses
could be used to overcome that. For example, use 20 bit SIDs universally
across MPLS and IPv6, and then copy them into the lower 20 bits of a well
known IPv6 prefix during hop-by-hop encapsulation for IPv6 forwarding.

There is already 32 bit IPv6 forwarding plane compatible identifier that
there are already example mapping schemes for - IPv4 addresses as 32 bit
SIDs. They would have the advantage that a lot of protocols that may be
useful to SR are already compatible with them e.g. OSPFv3, BGP etc. The SRH
would carry 32 bit "IPv4 address" SIDs rather than 128 bit IPv6
addresses/SIDs.

Regards,
Mark.

> I recommend that SRv6 optimizes for Routing Extension header length and
> leverages the processing model exemplified by the RH0.
>
> In the examples below, a packet is routed from S to D, visiting I1, I2 and
> I3 along the way. The first example demonstrates how RH0 routes the packet.
> In this example, the Routing Extension Header is 50 bytes long. The second
> example demonstrates how SRH routes the same packet.  In this example, the
> routing Extension header is 66 bytes long.
>
>
> Ron
>
>

---

From: "Leddy, John" <[email-masked]>
Date: Wed, 18 Apr 2018 00:55:19 +0000

Mark,

I would think that today the 20bit MPLS label is becoming a little constraining; global labels, MPLS datacenters/hypervisors/containers, service chaining proposals… and across AS boundaries.

For applications where the source is building the V6 SRH and the path is outside a single domain (where processing of the SRH is expected), a 20bit SID (or mapped 32bit) seems a little short sited.

Given that ASICs are getting faster and “deeper” and much of the processing of the SRH is likely to be on software based routers and network processors in the future (which have much less concerns about the SRH depth) – why would we limit the SID from being 128 bits and capable of being a routable IPV6 address?

John

From: ipv6 <[email-masked]> on behalf of Mark Smith <[email-masked]>
Date: Tuesday, April 17, 2018 at 4:13 PM
To: "[email-masked]" <[email-masked]>
Cc: IPv6 List <[email-masked]>
Subject: Re: Processing the Routing Extension Headers ( was: 6man w.g. last call for <draft-ietf-6man-segment-routing-header-11.txt )

Hi Ron,

On 18 April 2018 at 00:29, Ron Bonica <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

So I'm wondering if SR really needs 128 bit Segment Identifiers (i.e. IPv6 addresses as SIDs)? If 20 bits are enough in an MPLS network, is 20 bits enough in an IPv6 network?

I can understand trying to use SIDs that are directly usable in the forwarding plane, however the resulting overhead size of using IPv6 addresses as 128 bit SIDs seems to be causing lots of issues.

I think a simple mapping scheme between big enough SIDs and IPv6 addresses could be used to overcome that. For example, use 20 bit SIDs universally across MPLS and IPv6, and then copy them into the lower 20 bits of a well known IPv6 prefix during hop-by-hop encapsulation for IPv6 forwarding.

There is already 32 bit IPv6 forwarding plane compatible identifier that there are already example mapping schemes for - IPv4 addresses as 32 bit SIDs. They would have the advantage that a lot of protocols that may be useful to SR are already compatible with them e.g. OSPFv3, BGP etc. The SRH would carry 32 bit "IPv4 address" SIDs rather than 128 bit IPv6 addresses/SIDs.

Regards,
Mark.

Given that:

                                                                          Ron

                                           Segment List[0] = D
                                           Segment List[1] = I3
                                           Segment List[2] = I2
                                           Segment List[3] = I1

                                           Segment List[0] = D
                                           Segment List[1] = I3
                                           Segment List[2] = I2
                                           Segment List[3] = I1

                                           Segment List[0] = D
                                           Segment List[1] = I3
                                           Segment List[2] = I2
                                           Segment List[3] = I1

                                           Segment List[0] = D
                                           Segment List[1] = I3
                                           Segment List[2] = I2
                                           Segment List[3] = I1

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Wed, 18 Apr 2018 20:19:47 +0000

Hi John,

You raise a good point! 

But I think that this is another tradeoff between SRH Length and SRH processing cost. And again, since ASICs are fast and getting faster, I would optimize to reduce the SRH length.

The following are a few details for folks who aren't as familiar with the HMAC TLV as you and me:

The HMAC TLV is an optional TLV that is used to authenticate selected SRH fields, including the Segment List. On any given SRv6 path, the source and all upstream segment endpoints share a secret. When an SRv6  source originates a packet, it uses the shared secret to compute a MAC over the above-mentioned fields (including the Segment List). The SRv6 source node then stores the MAC in the HMAC TLV.

Since each upstream segment endpoint knows the secret that was used to produce the MAC, it can authenticate the fields over which the MAC was computed (including the Segment List).

HMAC processing, as currently defined in draft-ietf-6man-segment-routing-header, only works if the Segment List does not change as it travels from source to destination. It would not work for RHO-style processing, where the segment list does change as it travels from source to destination.

However, HMAC processing could be modified so that validating restore the Segment List to its original state before computing the HMAC. Yes, this adds computational cost to HMAC processing, but that cost is probably negligible compared to the cost of computing the MAC.

Beyond this, according to Section 6.2.2:

 "the HMAC field is used only when SRH is added by a device (such as a home set-up box) which is outside of the segment routing domain. If the SRH is added by a router in the trusted segment routing domain, then, there is no need for an HMAC field, hence no performance impact."

So, it appears that the HMAC protects against:

- spoofing the source address
- modification of the SRH between the source and the SRv6 domain ingress node

For the former, you only need to calculate the MAC over the IPv6 source address. 

For the latter, you might need to compute the MAC over the IPv6 destination address also, since modification of the destination address is just as dangerous as modification of the Segment List.

Having considered all of this, we might want to reconsider the HMAC TLV altogether. Maybe push it off onto another draft? What do you think?

                                                                             Ron

> -----Original Message-----
> From: Leddy, John <[email-masked]>
> Sent: Tuesday, April 17, 2018 11:18 AM
> To: Ron Bonica <[email-masked]>; IPv6 List <[email-masked]>
> Subject: Re: Processing the Routing Extension Headers ( was: 6man w.g. last
> call for <draft-ietf-6man-segment-routing-header-11.txt )
> 
> Ron,
> 
> 
> 
> Trying to "fix" the header to be what the source had originally set in order to
> verify the HMAC seems a little convoluted.
> 
> 
> 
> John
> 
> 
> 
> On 4/17/18, 10:30 AM, "ipv6 on behalf of Ron Bonica" <ipv6-
> [email-masked] on behalf of [email-masked]> wrote:
> 
> 
> 
>     Folks,
> 
> 
> 
>     The RHO model is more computationally expensive than the SRH model,
> but it reduces the size of the Routing Extension header by 16 bytes. The SRH
> model is less computationally expensive than the RH0 model, but it increases
> the size of the Routing Extension header by 16 bytes.
> 
> 
> 
>     Given that:
> 
> 
> 
>     In the examples below, a packet is routed from S to D, visiting I1, I2 and I3
> along the way. The first example demonstrates how RH0 routes the packet.
> example demonstrates how SRH routes the same packet.  In this example,
> the routing Extension header is 66 bytes long.
> 
> 
> 
>                                                                               Ron
> 
> 
> 
> 
> 
>     Administrative Requests:
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_ipv6&d=DwIGaQ&c=HAkYuh63rsuhr6S
> cbfh0UjBXeMK-ndb3voDTXcWzoCI&r=Fch9FQ82sir-BoLx84hKuKwl-
> AWF2EfpHcAwrDThKP8&m=-0aylaZlNG9T3kteX_JzEDarE8j9GjB9O4ufNC-
> Q92o&s=9BJ9_OJxHxDw2ePzHFq2bMkZ_8SXhzDP-gFpPC0U3K0&e=
>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 30 Apr 2018 10:36:58 +0000

Chairs,

At the bottom of this message, I recommend that the WG reconsider the HMAC TLV altogether. Is this reflected anywhere in the issue tracker?

It may just be an issue for discussion, but we should probably track it.

                                                 Ron

> From: Ron Bonica
> Sent: Wednesday, April 18, 2018 4:20 PM
> To: Leddy, John <[email-masked]>; IPv6 List <[email-masked]>
> Subject: RE: Processing the Routing Extension Headers ( was: 6man w.g. last
> But I think that this is another tradeoff between SRH Length and SRH
> processing cost. And again, since ASICs are fast and getting faster, I would
> optimize to reduce the SRH length.
> 
> The HMAC TLV is an optional TLV that is used to authenticate selected SRH
> fields, including the Segment List. On any given SRv6 path, the source and all
> upstream segment endpoints share a secret. When an SRv6  source
> originates a packet, it uses the shared secret to compute a MAC over the
> above-mentioned fields (including the Segment List). The SRv6 source node
> then stores the MAC in the HMAC TLV.
> 
> Since each upstream segment endpoint knows the secret that was used to
> produce the MAC, it can authenticate the fields over which the MAC was
> computed (including the Segment List).
> 
> HMAC processing, as currently defined in draft-ietf-6man-segment-routing-
> header, only works if the Segment List does not change as it travels from
> source to destination. It would not work for RHO-style processing, where the
> segment list does change as it travels from source to destination.
> 
> However, HMAC processing could be modified so that validating restore the
> Segment List to its original state before computing the HMAC. Yes, this adds
> computational cost to HMAC processing, but that cost is probably negligible
> compared to the cost of computing the MAC.
> 
>  "the HMAC field is used only when SRH is added by a device (such as a home
> set-up box) which is outside of the segment routing domain. If the SRH is
> added by a router in the trusted segment routing domain, then, there is no
> need for an HMAC field, hence no performance impact."
> 
> For the latter, you might need to compute the MAC over the IPv6 destination
> address also, since modification of the destination address is just as
> dangerous as modification of the Segment List.
> 
> Having considered all of this, we might want to reconsider the HMAC TLV
> altogether. Maybe push it off onto another draft? What do you think?
> 
>                                                                              Ron
> 
> 
> 
> 
> 
> 
> > Subject: Re: Processing the Routing Extension Headers ( was: 6man w.g.
> > last call for <draft-ietf-6man-segment-routing-header-11.txt )
> >
> > Ron,
> >
> >
> >
> > Trying to "fix" the header to be what the source had originally set in
> > order to verify the HMAC seems a little convoluted.
> >
> >
> >
> > John
> >
> >
> >
> >     There are two models for processing the Routing Extension headers.
> > The first model is exemplified by. The second is exemplified by the SRH.
> >
> >
> >
> >     The RHO model is more computationally expensive than the SRH
> > model, but it reduces the size of the Routing Extension header by 16
> > bytes. The SRH model is less computationally expensive than the RH0
> > model, but it increases the size of the Routing Extension header by 16
> bytes.
> >
> >
> >
> >     Given that:
> >
> >
> >
> >     I recommend that SRv6 optimizes for Routing Extension header
> > length and leverages the processing model exemplified by the RH0.
> >
> >
> >
> >     In the examples below, a packet is routed from S to D, visiting
> > I1, I2 and I3 along the way. The first example demonstrates how RH0 routes
> the packet.
> > In this example, the Routing Extension Header is 50 bytes long. The
> > second example demonstrates how SRH routes the same packet.  In this
> > example, the routing Extension header is 66 bytes long.
> >
> >
> >
> >
> > Ron
> >
> >
> >
> >
> >
> >     SRH Example (Copied from Darren's previous email and correcting
> > Hdr Ext
> > Len)
> >
> >