Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-01.txt

From: [email-masked]
Date: Wed, 03 Jul 2019 02:05:04 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Source Packet Routing in Networking WG of the IETF.

        Title           : SRv6 Network Programming
        Authors         : Clarence Filsfils
                          Pablo Camarillo Garvia
                          John Leddy
                          Daniel Voyer
                          Satoru Matsushima
                          Zhenbin Li
	Filename        : draft-ietf-spring-srv6-network-programming-01.txt
	Pages           : 41
	Date            : 2019-07-03

Abstract:
   This document describes the SRv6 network programming concept and its
   most basic functions.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Andrew Alston <[email-masked]>
Date: Wed, 3 Jul 2019 14:09:58 +0000

Dear Authors,

I've read through this draft with some interest - and it would be remiss of me not to express severe reservations to something that modified packet headers in the manner described.

As such, I've got a couple of questions.

  1.  What effect will this have on flow analysis if a packet is arriving with a modified DA - that is going to subsequently change
  2.  What effect will this have on inline systems that draw information from both the SA and DA addresses (think DPI systems)
  3.  I have significant concerns that the utilization of an IPv6 address in the manner described here could have under unintended and as of yet unknown consequences.  As an example, if filtering is done based on destination address, does it not stand to reason that you create an attack vector by allowing an extended next-hop header to programmatically change that which is being filtered on, on the preceding hop.  (Yes this is highly theoretical, but - I'd like to hear the authors comments on this)

Looking forward to the response

Yours Sincerely

Andrew Alston

From: spring <[email-masked]> On Behalf Of [email-masked]
Sent: Wednesday, 3 July 2019 12:05
To: [email-masked]
Cc: [email-masked]
Subject: [spring] I-D Action: draft-ietf-spring-srv6-network-programming-01.txt

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/<https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/>

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01<https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-01>
https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-01<https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-network-programming-01>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-01<https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-srv6-network-programming-01>

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/<ftp://ftp.ietf.org/internet-drafts/>

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://www.ietf.org/mailman/listinfo/spring>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 3 Jul 2019 16:34:51 +0200

Hi Andrew,

As just a little contributor to the spec let me provide my own personal
view point.

Please kindly see inline ...

>    1. What effect will this have on flow analysis if a packet is arriving
>    with a modified DA – that is going to subsequently change
>
> Flow analysis needs to recognize complete packet header (when ultimate
packet DST resides) to calculate the truth about end to end flows. Sure it
will take some time to build support around it, but this is nothing new.
When you UDP ir GRE tunnel around some flows you have the same issue. See
it took some time to perform decent flow analysis for MPLS packets. Frankly
if I look at linux kernel even today there is no efficient support for
hashing to multiple buffers from header above IP - so each time I need to
get packet headers to my flow analysis software I need to add few lines and
rebuild the kernel. Patch has been proposed long time back but it seems
kernel maintainers do not understands the problem.

>
>    1.
>    2. What effect will this have on inline systems that draw information
>    from both the SA and DA addresses (think DPI systems)
>
>
Same answer as above.

>    1.
>    2. I have significant concerns that the utilization of an IPv6 address
>    in the manner described here could have under unintended and as of yet
>    unknown consequences.  As an example, if filtering is done based on
>    destination address, does it not stand to reason that you create an attack
>    vector by allowing an extended next-hop header to programmatically change
>    that which is being filtered on, on the preceding hop.  (Yes this is highly
>    theoretical, but – I’d like to hear the authors comments on this)
>
>
It is trivial issue. You match on the DST in the SRH if different from your
packet's outer header DST field.

See in general network programmability is not an easy concept. It is almost
like monolith linux kernal vs dynamically loadable modular one. There was
huge resistance when this got introduced, but flexibility behind it won.

Same for networking in general. See few years back Nick and his team rolled
out OF. Well the mistake they did was the centralized approach and
programming way too much to each network element.

Proposed SRv6 NP is a new concept and likely it will take years to fully
adopt and see blossom of its power - but even now at such early stage you
can see islands benefiting from it already at some focused areas (5G
rollouts).

Yes I understand that as author of SRv6+ you want to save the legacy ASICs
and keep the packet headers as small as possible - keeping programmability
to the endpoints. Well if so I really see no reason why instead of this new
SRv6+ proposal we eliminate overhead to zero yet allow flexible traffic
steering with BGP Vector Routing as described here:
https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-07

Many thx,
Robert