Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

From: Sander Steffann <[email-masked]>
Date: Tue, 19 Oct 2021 23:18:53 +0200

Hi,

> When NEXT-C-SID is introduced, the Routing extension header can disappear entirely. So, where did the routing information that it once contained go? The FIB didn't change! We must be encoding it somewhere! So, any attempt to say that we are not encoding routing information in the IPv6 Destination Address field can be easily dismissed. Furthermore, encoding routing information in an address field *does* change the architectural description of that field.

As an operator this troubles me a lot. An IPv6 packet without a routing header where the destination address is NOT the final destination is as good as impossible to debug. Especially if that destination address comes from the normal unicast space with nothing to distinguish it from normal traffic.

Introducing such behaviour basically brings SR to the level of NAT in terms of opaqueness and confusion when debugging operational problems. 

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Oct 2021 10:49:27 +0100

Sander Steffann wrote on 19/10/2021 22:18:
> As an operator this troubles me a lot. An IPv6 packet without a
> routing header where the destination address is NOT the final
> destination is as good as impossible to debug. Especially if that
> destination address comes from the normal unicast space with nothing
> to distinguish it from normal traffic.
> 
> Introducing such behaviour basically brings SR to the level of NAT in
> terms of opaqueness and confusion when debugging operational
> problems.
as far as I can understand it, it's worse from a support from point of 
view, in the sense that the srh compression draft specifies that the SID 
argument contains the list of SIDs, but not the length of the SIDs.

Let's say you're an operator and you're trying to debug a forwarding 
problem using a dump of an SRv6 packet, and you throw the dump into a 
packet dissector like Wireshark, then Wireshark has no objective way to 
decode the list of SIDs in the packet without being manually told what 
length of the compressed SIDs are.

In other words, this draft specifies a network protocol which has data 
structures which cannot be decoded without reference to information 
which is not provided in the packet structure. It doesn't take a genius 
to understand that this is the sort of thing that can impact both the 
cost and the reliability of a network.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Wed, 20 Oct 2021 12:21:22 +0200

Hi Nick,

> In other words, this draft specifies a network protocol which has data structures which cannot be decoded without reference to information which is not provided in the packet structure. It doesn't take a genius to understand that this is the sort of thing that can impact both the cost and the reliability of a network.

You’re right, it is worse than I thought. This is not something that should be standardised.

Cheers,
Sander

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 20 Oct 2021 11:04:57 +0000

Hi all,
If there is a label in the MPLS stack then how to understand what is it? TE? VLL? L2VPN? L3VPN?
Wireshark would not answer.
How have people there living with the MPLS data plane for the last 22 years?
We should inform them that it "impacts both the cost and the reliability of a network".

The current practices keep a lot of information in some tables on routers that are synchronized by the control plane.
"Programmability" is trying to move some states to the data plane.
The example below shows that "not enough programmability" because Wireshark would be still not capable to understand everything just from the packet.

Conclusion:
Nick, Sander, if you like for Wireshark to understand everything from the packet
Then you have to ask more "programmability" not less.

I am not sure that the "Wireshark test" is so much important.
Of course, it would be nice to understand the structure of the whole Universe from just 1 packet on the Internet.
But it is probably too strong a requirement.

Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Sander Steffann
Sent: Wednesday, October 20, 2021 1:21 PM
To: Nick Hilliard <[email-masked]>
Cc: [email-masked]
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Nick,

Cheers,
Sander
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Oct 2021 12:46:53 +0100

> We should inform them that it "impacts both the cost and the reliability of a network".

Couple of things here: first, mpls labels are a fixed size, so the mpls 
equivalent of this draft is straightforward to interpret.  You're right 
to point out that what happens inside the label stack is a different 
issue, but we have 20 years of mpls tooling and understanding which 
helps in this regard.

The second thing is that you're perilously close to arguing that just 
because something which is a bad idea has been implemented in one area, 
that it's sensible to make the same mistake in another area.

Encoding the length is something that could be done easily and there are 
a couple of options on the table for compressed SID encoding where it's 
already there.

Nick

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 20 Oct 2021 12:19:02 +0000

Indeed, it is a little different what we would not understand:
- in the MPLS case we see the structure but do not understand what it means (MPLS DT is working in the direction to create variable size metadata blocks for us not to understand the structure, keep patience)
- in a general "programmable" data plane we may not understand even the structure of a particular block.

Nick, Why do you see a big difference here? We do not understand what it means anyway.

If we would ask assistance from the control plane then we could understand anything in both cases.
The argument that "we have 20 years of MPLS tooling and understanding which helps in this regard" means in reality:
Please, stop inventing new things because we would need to develop new tools.
Eduard
-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Wednesday, October 20, 2021 2:47 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Sander Steffann <[email-masked]>; [email-masked]
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

> We should inform them that it "impacts both the cost and the reliability of a network".

Couple of things here: first, mpls labels are a fixed size, so the mpls equivalent of this draft is straightforward to interpret.  You're right to point out that what happens inside the label stack is a different issue, but we have 20 years of mpls tooling and understanding which helps in this regard.

The second thing is that you're perilously close to arguing that just because something which is a bad idea has been implemented in one area, that it's sensible to make the same mistake in another area.

Encoding the length is something that could be done easily and there are a couple of options on the table for compressed SID encoding where it's already there.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Wed, 20 Oct 2021 15:24:02 +0200

Hi,

> - in the MPLS case we see the structure but do not understand what it means

This is actually one of the main advantages of SRv6: it provides a much easier to debug label stack. 

> - in a general "programmable" data plane we may not understand even the structure of a particular block.

Yep. And the combination of variable label size + not encoding the size + the opaqueness of network programming functions + a multitude of SID compression ways that can’t be distinguished from looking at the packet creates a nightmare that operators desperately want to prevent. 

Opaque hop-by-hop labels (MPLS) are annoying to debug. Opaque network-wide labels (SR-MPLS, CRH) are already a lot easier. Network-wide labels that match routing (SRH) are a breath of fresh air. And compression styles that make it impossible to even determine what the labels are from looking at the packet throws the whole thing back beyond just annoying to unworkable. 

That’s why this is a bad development for operators, and as an operator I’m hoping that the IETF is finally ready to consider these issues as valid technical arguments.

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Oct 2021 15:00:01 +0100

> Nick, Why do you see a big difference here? We do not understand what it means anyway.

this conversation has become very peculiar. Your argument for not doing 
something sensible and rational seems to be: "well it's awful over 
there, so that means it's ok for it to be awful over here too".

So back to basics: this protocol proposes repurposing an existing field 
in IPv6 and using it to insert a list of SIDs of some arbitrary size 
defined by the operator.  As the packet traverses the intermediate SR 
nodes on the network, each of these nodes left-shifts the sequence of 
SIDs to find out the next SR intermediate node.

The length of these SIDs is not defined in the packet. The draft does 
not even specify that all the SIDs need to be the same size (except for 
NEXT-and-REPLACE-C-SID).

Here are some reasons why you might want to encode the SID length:

1. it is impossible to debug SID-related problems without adequate 
tooling and if your tooling needs manual external input to dissect a 
packet, this increases the support + troubleshooting cost of running a 
SRv6 network.

2. there is no prohibition in the srh compression draft about using 
different SID lengths in the same domain (except for 
NEXT-and-REPLACE-C-SID).

3. SRv6 RFCs and IDs admit multi-domain SRv6 deployments.  How does it 
work when different domains use different SID lengths and when you want 
the domains to interoperate in a unified way?

4. Without being able to specify the size of the SID, there is no way of 
changing SID size on an operational network without a flag day.

Nick

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 20 Oct 2021 15:40:37 +0000

Hi Nick, Your position is not logical.
If you need more information in the packet itself (even more programmability) - go to SPRING and propose what else to insert.
For example, "type of processing method" or "Compressed SID length".
Because instead of requesting what you want, You propose to completely cancel the activity in this direction.

Again:
1. Data Plane Programmability is minimal now (see MPLS).
2. SPRING introduces much more.
3. You demand even more.
It is not the reason to cancel what SPRING is doing and go to state #1 whereas you said: "it was awful".

With strong demand for "Wireshark to decode everything in the packet with minimal control plane support"
You look like a strong supporter of CSID. Because it is at least half a step in the direction of what you want.

Ed/
-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]] 
Sent: Wednesday, October 20, 2021 5:00 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Sander Steffann <[email-masked]>; [email-masked]
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Vasilenko Eduard wrote on 20/10/2021 13:19:
> - in the MPLS case we see the structure but do not understand what it 
> means (MPLS DT is working in the direction to create variable size 
> metadata blocks for us not to understand the structure, keep patience)

this conversation has become very peculiar. Your argument for not doing something sensible and rational seems to be: "well it's awful over there, so that means it's ok for it to be awful over here too".

So back to basics: this protocol proposes repurposing an existing field in IPv6 and using it to insert a list of SIDs of some arbitrary size defined by the operator.  As the packet traverses the intermediate SR nodes on the network, each of these nodes left-shifts the sequence of SIDs to find out the next SR intermediate node.

The length of these SIDs is not defined in the packet. The draft does not even specify that all the SIDs need to be the same size (except for NEXT-and-REPLACE-C-SID).

1. it is impossible to debug SID-related problems without adequate tooling and if your tooling needs manual external input to dissect a packet, this increases the support + troubleshooting cost of running a
SRv6 network.

2. there is no prohibition in the srh compression draft about using different SID lengths in the same domain (except for NEXT-and-REPLACE-C-SID).

3. SRv6 RFCs and IDs admit multi-domain SRv6 deployments.  How does it work when different domains use different SID lengths and when you want the domains to interoperate in a unified way?

4. Without being able to specify the size of the SID, there is no way of changing SID size on an operational network without a flag day.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 20 Oct 2021 18:24:37 +0200

Nick,

You have a valid point - no doubt. SRv6 already has a wireshark dissector.
I guess the best is to wait and see how it will work with cSID (with or
without SRH present) instead of speculating. SPRING discussion is about WG
acceptance not WG LC or IETF LC. After the draft is accepted it is very
valid to bring those operational issues to the table.

However to the point Steffan wrote I can only say - don't use it. It is not
mandatory. Your network can be SR free or cSID free at your own will for
years to come.

Debugging the network is very important and if you do not have the right
tools - you lose. But adding control plane awareness to the packet decoder
is not rocket science. In fact you do not even need to add a control plane
- all you need to set is your internal prefix for filtering which when you
use wireshark you are already doing to scope the information,

Let's also not forget that this is only the outer IPv6 header we keep
talking about. Behind this there is the original IPv6 header which can be
in many cases sufficient for troubleshooting.

As with any encapsulation I would be much more concerned if those packets
can be correctly processed by IPS or Firewalls - but I guess this is
something to take up with those who make such network elements.

Best,
Robert.

On Wed, Oct 20, 2021 at 4:00 PM Nick Hilliard <[email-masked]> wrote:

> means (MPLS DT is working in the direction to create variable size metadata
> blocks for us not to understand the structure, keep patience)

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 20 Oct 2021 21:30:37 +0100

Robert Raszuk wrote on 20/10/2021 17:24:
> dissector. I guess the best is to wait and see how it will work with 
> cSID (with or without SRH present) instead of speculating.

Robert,

In fact we don't need to wait or see.  If a dissector doesn't know the 
SID length without explicitly being told by the operator, it can't 
decode it properly.

If the SID length is not encoded in the packet, then the network cannot 
be changed to use a different SID length without a flag day, and 
inter-domain SRv6 is going to be a problem where multi-domain network 
layouts use different c-sid lengths.

No speculation is needed to work this out :-)

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 20 Oct 2021 22:44:32 +0200

Nick,

Unlike global c-SIDs (section 5.1) to me local c-SIDs (section 5.2) are the
crux of the proposal. They are going to be known and properly switched only
by the node which advertised them (Locator Node).

It is a bit like locally significant MPLS labels.

Yes MPLS header is different, has fixed size and has EoS bit - all true so
it is trivial to skip it. Same here you can skip out IPv6 encap all
together too.

For shark analogy it is comparable ... you do not know what is the
intention of the next node when it seems one of the local labels nor local
c-SIDs.

And as I said - I do not want to smooth your valid observation. But just to
position it correctly as to other technologies already in use.

Wireshark will decode IPv6 SA or DA or SIDs in SRH as IPv6 addresses
XXXX:YYYY:VVVV::ZZZZ no more no less. What it means will be up to your own
naked or armed eye interpretation/processing.

Best,
R.

---

From: Stefano Salsano <[email-masked]>
Date: Wed, 20 Oct 2021 23:36:35 +0200

Hi,

I'm leading the ROSE (Research on Open SRv6 Ecosystem) project which 
builds up and maintains an Open Ecosystem for SRv6.

As part of this project, we added support for SRv6 across many 
open-source stacks including Linux, P4, eBPF, TCPDUMP, Wireshark, and 
many others.

We already developed various features on top of the the SRv6 dissector 
in Wireshark. We are currently enhancing it to support CSID (we'll send 
out an update once it is available).

I can anticipate that it is possible to use wireshark to dissect CSID 
packets, by providing very simple configuration information. It is very 
common to need such configuration information when using wireshark in 
real operational networks, for example the wireshark feature "decode as" 
is exactly meant for this purpose.

Stefano

-- 
*******************************************************************
Stefano Salsano
Professore Associato
Dipartimento Ingegneria Elettronica
Universita' di Roma Tor Vergata
Viale Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435
*******************************************************************

---

From: Andrew Alston <[email-masked]>
Date: Thu, 21 Oct 2021 05:54:42 +0000

Ok - so, while we are talking about operational issues - here is another problem.

The default for MPLS is what I would term something close to a "fail closed" scenario.  That is to say - if you don't explicitly enable MPLS on the borders of your network - because its got its own ether-type etc - chances are on most gear, those packets aren't going anywhere.  Same goes for servers.  Now, people say, this is limited-domain and you apply access lists to stop leakage.  Except - because this stuff is now bedded into a v6 address that isn't a v6 address - the default is now pass.

So - we say - filtering at the edge of the network - everyone does that no problem.  Except - not only does an operator now have to filter at the border of their network, but they also now have to filter on every port facing every server if they want to protect themselves from the servers sending funky packets into the network.  (Think servers that are protected by host based firewalls or other such where you wouldn't normally access list on the router ports themselves). This gets even more interesting when you wanna limit this stuff moving into cloud-based networks - where you want to allow this stuff through to some parts of it or another.  Effectively - by dumping this stuff into "v6 addresses" the border of the network has been smudged and blurred from this perspective.

That's not a pretty picture...

Andrew

From: ipv6 <[email-masked]> On Behalf Of Vasilenko Eduard
Sent: Wednesday, October 20, 2021 6:41 PM
To: Nick Hilliard <[email-masked]>
Cc: [email-masked]
Subject: RE: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Again:

Ed/
-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]]
Sent: Wednesday, October 20, 2021 5:00 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Sander Steffann <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

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

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 21 Oct 2021 08:15:03 +0000

Hi Andrew,
I suspect that this security hole does not exist because we could have 2 situations here:

1.       SRv6 routing header is absent. Then would be no special SRv6 processing. Then DA would be treated as a normal destination. It is normal if somebody would send traffic to the black hole. The maximum that he would get is "destination unreachable". It could happen in any network now.

2.       SRv6 routing header is present. Then it is under the filtering requirement for the SRv6 domain border. It is easy to drop just because RH is present. Such drop is already requested by all specifications on SRv6. Maybe draft-filsfilscheng-spring-srv6-srh-compression is not vocal enough on this subject - see below for the only statement it has.

SRv6 is claimed to be designed for Trusted environments only:
*       Segment routing architecture (RFC 8402) section 8
*       SRH - Segment Routing Header (RFC 8754) section 5
*       SRv6 Network Programming (RFC8986) section 9

*       draft-filsfilscheng-spring-srv6-srh-compression: "The security requirements and mechanisms described in [RFC8402<https://datatracker.ietf.org/doc/html/rfc8402>] and [RFC8754<https://datatracker.ietf.org/doc/html/rfc8754>] also apply to this document".
SRH RFC is especially verbal how to filter out any SR-related information on the border of the "SR domain".
Eduard
From: Andrew Alston [mailto:[email-masked]]
Sent: Thursday, October 21, 2021 8:55 AM
To: Vasilenko Eduard <[email-masked]>; Nick Hilliard <[email-masked]>
Cc: [email-masked]
Subject: RE: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Andrew

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Vasilenko Eduard
Sent: Wednesday, October 20, 2021 6:41 PM
To: Nick Hilliard <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Again:

Ed/
-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]]
Sent: Wednesday, October 20, 2021 5:00 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Sander Steffann <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Nick

---

From: Andrew Alston <[email-masked]>
Date: Thu, 21 Oct 2021 08:25:33 +0000

Yes, And I see plenty of issues with 8986 - and in fact with all of what you are mentioning in this regard in relation to what I have said.

And again - just because we made mistakes before - doesn't mean we need to repeat them.

Fact is - dropping SRH at each port that faces a server creates complexity - and it still a fail-open scenario. That's a problem - and I'd be curious to hear v6ops comment on this issue as well from an operational standpoint - and also be curious to see if sec area didn't have any thoughts on this.

Andrew

From: Vasilenko Eduard <[email-masked]>
Sent: Thursday, October 21, 2021 11:15 AM
To: Andrew Alston <[email-masked]>
Cc: [email-masked]
Subject: RE: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Andrew,

To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; Nick Hilliard <[email-masked]<mailto:[email-masked]>>

Andrew

Again:

Ed/
-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]]
Sent: Wednesday, October 20, 2021 5:00 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Sander Steffann <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Nick

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Oct 2021 10:27:01 +0100

Hi Andrew,

Two questions below, if you don't mind expanding a bit.

On Thu, Oct 21, 2021 at 9:27 AM Andrew Alston <Andrew.Alston=
[email-masked]> wrote:

> Yes, And I see plenty of issues with 8986 – and in fact with all of what
> you are mentioning in this regard in relation to what I have said.
>
>
>
> And again – just because we made mistakes before – doesn’t mean we need to
> repeat them.
>
>
>
> Fact is – dropping SRH at each port that faces a server creates complexity
>

Would you describe the filtering required for ULAs as similar to this?

> – and it still a fail-open scenario. That’s a problem – and I’d be curious
> to hear v6ops comment on this issue as well from an operational standpoint
> – and also be curious to see if sec area didn’t have any thoughts on this.
>

I don't think I see a new threat model here; can you describe what the
security area would comment on?

thanks,

Ted Hardie

>
>
> Andrew
>
>
>
>
>
> *From:* Vasilenko Eduard <[email-masked]>
> *Sent:* Thursday, October 21, 2021 11:15 AM
> *To:* Andrew Alston <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: Question from SPRING regarding
> draft-filsfilscheng-spring-srv6-srh-compression
>
>
>
> Hi Andrew,
>
>    1. SRv6 routing header is absent. Then would be no special SRv6
>    processing. Then DA would be treated as a normal destination. It is normal
>    if somebody would send traffic to the black hole. The maximum that he would
>    get is “destination unreachable”. It could happen in any network now.
>    2. SRv6 routing header is present. Then it is under the filtering
>    requirement for the SRv6 domain border. It is easy to drop just because RH
>    is present. Such drop is already requested by all specifications on SRv6.
>    Maybe draft-filsfilscheng-spring-srv6-srh-compression is not vocal enough
>    on this subject – see below for the only statement it has.
>
>
>
>    - Segment routing architecture (RFC 8402) section 8
>    - SRH - Segment Routing Header (RFC 8754) section 5
>    - SRv6 Network Programming (RFC8986) section 9
>    - draft-filsfilscheng-spring-srv6-srh-compression: “The security
>    requirements and mechanisms described in [RFC8402
>    <https://datatracker.ietf.org/doc/html/rfc8402>] and [RFC8754
>    <https://datatracker.ietf.org/doc/html/rfc8754>] also apply to this
>    document”.
>
> SRH RFC is especially verbal how to filter out any SR–related information
> on the border of the “SR domain”.
>
> Eduard
>
> *From:* Andrew Alston [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Thursday, October 21, 2021 8:55 AM
> *To:* Vasilenko Eduard <[email-masked]>; Nick Hilliard <
> [email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: Question from SPRING regarding
> draft-filsfilscheng-spring-srv6-srh-compression
>
>
>
> Ok – so, while we are talking about operational issues – here is another
> problem.
>
>
>
> The default for MPLS is what I would term something close to a “fail
> closed” scenario.  That is to say – if you don’t explicitly enable MPLS on
> the borders of your network – because its got its own ether-type etc –
> chances are on most gear, those packets aren’t going anywhere.  Same goes
> for servers.  Now, people say, this is limited-domain and you apply access
> lists to stop leakage.  Except – because this stuff is now bedded into a v6
> address that isn’t a v6 address – the default is now pass.
>
>
>
> So – we say – filtering at the edge of the network – everyone does that no
> problem.  Except – not only does an operator now have to filter at the
> border of their network, but they also now have to filter on every port
> facing every server if they want to protect themselves from the servers
> sending funky packets into the network.  (Think servers that are protected
> by host based firewalls or other such where you wouldn’t normally access
> list on the router ports themselves). This gets even more interesting when
> you wanna limit this stuff moving into cloud-based networks – where you
> want to allow this stuff through to some parts of it or another.
> Effectively – by dumping this stuff into “v6 addresses” the border of the
> network has been smudged and blurred from this perspective.
>
>
>
> That’s not a pretty picture…
>
>
>
> Andrew
>
>
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of *Vasilenko Eduard
> *Sent:* Wednesday, October 20, 2021 6:41 PM
> *To:* Nick Hilliard <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: Question from SPRING regarding
> draft-filsfilscheng-spring-srv6-srh-compression
>
>
>
> If you need more information in the packet itself (even more
> programmability) - go to SPRING and propose what else to insert.
> From: Nick Hilliard [mailto:[email-masked] <[email-masked]>]
> Subject: Re: Question from SPRING regarding
> draft-filsfilscheng-spring-srv6-srh-compression
>
> something sensible and rational seems to be: "well it's awful over there,
> so that means it's ok for it to be awful over here too".
>
> So back to basics: this protocol proposes repurposing an existing field in
> IPv6 and using it to insert a list of SIDs of some arbitrary size defined
> by the operator. As the packet traverses the intermediate SR nodes on the
> network, each of these nodes left-shifts the sequence of SIDs to find out
> the next SR intermediate node.
>
> The length of these SIDs is not defined in the packet. The draft does not
> even specify that all the SIDs need to be the same size (except for
> NEXT-and-REPLACE-C-SID).
>
> 1. it is impossible to debug SID-related problems without adequate tooling
> and if your tooling needs manual external input to dissect a packet, this
> increases the support + troubleshooting cost of running a
> SRv6 network.
>
> 3. SRv6 RFCs and IDs admit multi-domain SRv6 deployments. How does it work
> when different domains use different SID lengths and when you want the
> domains to interoperate in a unified way?
>

---

From: Andrew Alston <[email-masked]>
Date: Thu, 21 Oct 2021 09:47:51 +0000

I don’t see ULA’s in the same way – for a simple reason.

Firstly – it’s a fixed address block – reasonably easy to throw null routes around where I need to etc to stop propagation and steering.  With this stuff – not the case – its part of my central IPv6 block – and as demonstrated in other drafts – there may be multiple locators in the same domain – each time – I gotta filter each locator block – I can’t go nearly as wide.

Lets sketch a potential scenario – and as hypothetical as this is – and unlikely – it is simply meant to illustration one unknown possibility.

I take a server that I’ve hacked – I generate a packet – on the inner header of that packet – I set its destination as the server I’ve just hacked.  On the outer header – I apply a locator block – that steers this packet a bunch of nodes deep into the network.  I send the packet – the packet flows – it gets de-encapsulated at the final node in the path – that router – then sends that packet straight back at me.  On the server – I have XDP running that matches the return packet – diverts it to userland – reencaps – and send it out again.

And while this is untested – if I’m right and without giving this a ton of thought - I just created a big fat loop through that server on the network.

Could be some interesting code to write as proof of concept.  A single server now having lotsa fun when its compromised.

Andrew

From: ipv6 <[email-masked]> On Behalf Of Ted Hardie
Sent: Thursday, October 21, 2021 12:27 PM
To: Andrew Alston <Andrew.Alston=[email-masked]>
Cc: [email-masked]
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Andrew,

On Thu, Oct 21, 2021 at 9:27 AM Andrew Alston <Andrew.Alston=[email-masked]<mailto:[email-masked]>> wrote:
Yes, And I see plenty of issues with 8986 – and in fact with all of what you are mentioning in this regard in relation to what I have said.

And again – just because we made mistakes before – doesn’t mean we need to repeat them.

– and it still a fail-open scenario. That’s a problem – and I’d be curious to hear v6ops comment on this issue as well from an operational standpoint – and also be curious to see if sec area didn’t have any thoughts on this.

I don't think I see a new threat model here; can you describe what the security area would comment on?

thanks,

Ted Hardie

Andrew

From: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 21, 2021 11:15 AM
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Andrew,

  1.  SRv6 routing header is absent. Then would be no special SRv6 processing. Then DA would be treated as a normal destination. It is normal if somebody would send traffic to the black hole. The maximum that he would get is “destination unreachable”. It could happen in any network now.
  2.  SRv6 routing header is present. Then it is under the filtering requirement for the SRv6 domain border. It is easy to drop just because RH is present. Such drop is already requested by all specifications on SRv6. Maybe draft-filsfilscheng-spring-srv6-srh-compression is not vocal enough on this subject – see below for the only statement it has.

  *   draft-filsfilscheng-spring-srv6-srh-compression: “The security requirements and mechanisms described in [RFC8402<https://datatracker.ietf.org/doc/html/rfc8402>] and [RFC8754<https://datatracker.ietf.org/doc/html/rfc8754>] also apply to this document”.
SRH RFC is especially verbal how to filter out any SR–related information on the border of the “SR domain”.

Ok – so, while we are talking about operational issues – here is another problem.

The default for MPLS is what I would term something close to a “fail closed” scenario.  That is to say – if you don’t explicitly enable MPLS on the borders of your network – because its got its own ether-type etc – chances are on most gear, those packets aren’t going anywhere.  Same goes for servers.  Now, people say, this is limited-domain and you apply access lists to stop leakage.  Except – because this stuff is now bedded into a v6 address that isn’t a v6 address – the default is now pass.

So – we say – filtering at the edge of the network – everyone does that no problem.  Except – not only does an operator now have to filter at the border of their network, but they also now have to filter on every port facing every server if they want to protect themselves from the servers sending funky packets into the network.  (Think servers that are protected by host based firewalls or other such where you wouldn’t normally access list on the router ports themselves). This gets even more interesting when you wanna limit this stuff moving into cloud-based networks – where you want to allow this stuff through to some parts of it or another.  Effectively – by dumping this stuff into “v6 addresses” the border of the network has been smudged and blurred from this perspective.

Andrew

Again:

Ed/
-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]]
Sent: Wednesday, October 20, 2021 5:00 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Sander Steffann <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Oct 2021 11:02:07 +0100

Hi Stefano,

[spring@ re-added to cc:]

Stefano Salsano wrote on 20/10/2021 22:36:
> packets, by providing very simple configuration information.

This is exactly the problem though - operators will need to manually 
instruct a dissector how to interpret the packet contents and that 
defeats the purpose of a debugging tool because the tool is supposed to 
be able to objectively tell you what's going on, without the operator 
having to tell it what's going on.

In particular, if you're attempt to debug a problem relating to C-SID 
length, it would be completely useless.

For example, how would you dissect the following sequence of compressed 
SIDs of different lengths?

0x53b7e4f4d23b

The short answer is you can't objectively, yet this could be a valid SID 
argument.

There's an opportunity at this point to ensure that whatever compressed 
SID mechanism is implemented, that it's done in such a way if difference 
lengths of compressed SIDs are allowed, that the SID length is included 
in the encoding.

If this isn't done, it will create a mess which operations and support 
people will be stuck with for the lifetime of SRv6.  Note that this 
devalues SRv6 as an infrastructure component.

Nick

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Oct 2021 11:11:07 +0100

Hi Andrew,

On Thu, Oct 21, 2021 at 10:47 AM Andrew Alston <
[email-masked]> wrote:

> Firstly – it’s a fixed address block – reasonably easy to throw null
> routes around where I need to etc to stop propagation and steering.  With
> this stuff – not the case – its part of my central IPv6 block – and as
> demonstrated in other drafts – there may be multiple locators in the same
> domain – each time – I gotta filter each locator block – I can’t go nearly
> as wide.
>
>
>
Okay, so it's roughly the same mechanism, but made easier in the ULA case
by the allocation of the general ULA prefix.  Is that approximately correct?

> Lets sketch a potential scenario – and as hypothetical as this is – and
> unlikely – it is simply meant to illustration one unknown possibility.
>
>
>
> I take a server that I’ve hacked – I generate a packet – on the inner
> header of that packet – I set its destination as the server I’ve just
> hacked.  On the outer header – I apply a locator block – that steers this
> packet a bunch of nodes deep into the network.  I send the packet – the
> packet flows – it gets de-encapsulated at the final node in the path – that
> router – then sends that packet straight back at me.  On the server – I
> have XDP running that matches the return packet – diverts it to userland –
> reencaps – and send it out again.
>
>
>
And while this is untested – if I’m right and without giving this a ton of
> thought - I just created a big fat loop through that server on the
> network.
>

If you control both the emitting host and the server it's directing flows
to, it is far simpler to generate traffic than this, so I don't quite see
the threat here beyond the base network resource consumption you'd get with
any other host/compromised server pair.  What attack surface is the routing
method that brings the packet to the server exposing?

thanks,

Ted Hardie

>
>
> Could be some interesting code to write as proof of concept.  A single
> server now having lotsa fun when its compromised.
>
>
>
> Andrew
>
>
>
>
>
> *From:* ipv6 <[email-masked]> *On Behalf Of * Ted Hardie
> *Sent:* Thursday, October 21, 2021 12:27 PM
> *To:* Andrew Alston <Andrew.Alston=[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: Question from SPRING regarding

---

From: Andrew Alston <[email-masked]>
Date: Thu, 21 Oct 2021 10:14:22 +0000

The attack vector is that its creating a loop – between an undefined point in the network many nodes deep – that you do NOT have control over – and a single host

Host -> steer -> steer -> steer <deencap at end of sid list> -> unicast back to host <pick up, reencap, send to same sid list> - now you got a loop.

There is a reason we turned off source routing by default – there is a reason we deprecated RH0.

This stuff – is not exactly wonderfully safe.

Andrew

From: Ted Hardie <[email-masked]>
Sent: Thursday, October 21, 2021 1:11 PM
To: Andrew Alston <[email-masked]>
Cc: Andrew Alston <Andrew.Alston=[email-masked]>; [email-masked]
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Andrew,

On Thu, Oct 21, 2021 at 10:47 AM Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
I don’t see ULA’s in the same way – for a simple reason.

Okay, so it's roughly the same mechanism, but made easier in the ULA case by the allocation of the general ULA prefix.  Is that approximately correct?

If you control both the emitting host and the server it's directing flows to, it is far simpler to generate traffic than this, so I don't quite see the threat here beyond the base network resource consumption you'd get with any other host/compromised server pair.  What attack surface is the routing method that brings the packet to the server exposing?

thanks,

Ted Hardie

Andrew

From: ipv6 <[email-masked]<mailto:[email-masked]>> On Behalf Of Ted Hardie
Sent: Thursday, October 21, 2021 12:27 PM
To: Andrew Alston <Andrew.Alston=[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Andrew,

thanks,

Ted Hardie

Andrew

Hi Andrew,

Andrew

Again:

Ed/
-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]]
Sent: Wednesday, October 20, 2021 5:00 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Sander Steffann <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Nick

---

From: Andrew Alston <[email-masked]>
Date: Thu, 21 Oct 2021 10:21:22 +0000

Here is another theoretical attack vector.

Encap a v4 packet into an SRH – set the next header type to v4 – spoof the v4 source – set the v4 destination to an on net broadcast – urpf wont kick in – because its encapsulated – the auto-deencap at the end of the csid list chucks out a v4 packet – that in theory in certain circumstances – could then hit a broadcast – and dependent on config – you may have just created smurf v2 – and – since the original host is sending encapped packets from an inner source that’s pretty much invisible – could be interesting to track it out.

But basically – this theoretically – could be a potential way to bypass certain protection mechanisms to slide v4 packets into a network – and drop them behind places they wouldn’t normally get to

Andrew

Hi Andrew,

thanks,

Ted Hardie

Andrew

Hi Andrew,

thanks,

Ted Hardie

Andrew

Hi Andrew,

Andrew

Again:

Ed/
-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]]
Sent: Wednesday, October 20, 2021 5:00 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Sander Steffann <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Nick

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Oct 2021 11:49:02 +0100

Hi Andrew,

On Thu, Oct 21, 2021 at 11:14 AM Andrew Alston <
[email-masked]> wrote:

> The attack vector is that its creating a loop – between an undefined point
> in the network many nodes deep – that you do NOT have control over – and a
> single host
>
>
>
> Host -> steer -> steer -> steer <deencap at end of sid list> -> unicast
> back to host <pick up, reencap, send to same sid list> - now you got a loop.
>
>
Sorry for being dense here, but are you saying that the resources the
attacker is consuming are the queues in the specific routers through which
the flow is steered?  And that this is different from simply consuming the
network resources which would be consumed by simply emitting the same
packets with a standard source/destination pair?

This seems to presume that the attacker controls both emitter and server
and has access to the information required to steer the network through the
resources of interest.  In a parallel attack on an MPLS network, the
attacker would have access to a host, a server, and the information needed
to construct the MPLS label stack that steered the traffic through the
specific network nodes that they wanted to target.  Does that parallel
capture the attack you're getting at here?

Thanks,

Ted Hardie

> *From:* Ted Hardie <[email-masked]>
> *Sent:* Thursday, October 21, 2021 1:11 PM
> *Cc:* Andrew Alston <Andrew.Alston=[email-masked]>;
> [email-masked]
> *From:* ipv6 <[email-masked]> *On Behalf Of *Ted Hardie

---

From: Andrew Alston <[email-masked]>
Date: Thu, 21 Oct 2021 10:54:12 +0000

The difference here Ted, is very simple.

MPLS – is fail-closed.  The router itself – would need mpls explicitly enabled on the port facing the server to handle an mpls packet.

In this case – its not the same thing – these are v6 packets – tey will flow – unless you explicitly access list every single port to every single host server.  Once you get a server on the network that does not have explicit filtering on the ingress port on the router – because of the de-encap that occurs automatically at the end of the csid list – you can shove whatever you want behind that – its gonna de-encap and its gonna forward.  What it forwards – to where – and bypassing what rules that would normally be in place elsewhere – that’s a big giant question.

For example – BCP38 that says – do not allow a host to send into the network from addresses not assigned to it.  Except – the server itself is now sending from its own legitimate source address on the outer packet.  You hit one sid – it de-encaps – and now – you got a packet that was encapsulated – de-encapsulated and floating around on the network – having bypassed the BCP38 filtering.

You do not need access to the routers to do this – all you need to know is the Locator and a single SID on the network.

Andrew

Sent: Thursday, October 21, 2021 1:49 PM

Hi Andrew,

On Thu, Oct 21, 2021 at 11:14 AM Andrew Alston <[email-masked]<mailto:[email-masked]>> wrote:
The attack vector is that its creating a loop – between an undefined point in the network many nodes deep – that you do NOT have control over – and a single host

Sorry for being dense here, but are you saying that the resources the attacker is consuming are the queues in the specific routers through which the flow is steered?  And that this is different from simply consuming the network resources which would be consumed by simply emitting the same packets with a standard source/destination pair?

This seems to presume that the attacker controls both emitter and server and has access to the information required to steer the network through the resources of interest.  In a parallel attack on an MPLS network, the attacker would have access to a host, a server, and the information needed to construct the MPLS label stack that steered the traffic through the specific network nodes that they wanted to target.  Does that parallel capture the attack you're getting at here?

Thanks,

Ted Hardie

Andrew

From: Ted Hardie <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, October 21, 2021 1:11 PM
To: Andrew Alston <[email-masked]<mailto:[email-masked]>>
Cc: Andrew Alston <Andrew.Alston=[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Andrew,

thanks,

Ted Hardie

Andrew

Hi Andrew,

thanks,

Ted Hardie

Andrew

Hi Andrew,

Andrew

Again:

Ed/
-----Original Message-----
From: Nick Hilliard [mailto:[email-masked]]
Sent: Wednesday, October 20, 2021 5:00 PM
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
Cc: Sander Steffann <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Nick

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Oct 2021 12:16:59 +0100

Hi Andrew,

The MPLS parallel was simply to make sure I understood the threat model
you're putting forward correctly.  I was presuming an MPLS-enabled network
in that parallel, sorry that wasn't more explicit.  If you do presume an
MPLS-enabled network, does that parallel describe what resources you
believe the attackers are targeting?

I've read your comments below, and I think that it would be helpful if you
could unpack this:

"its gonna de-encap and its gonna forward.  What it forwards – to where –
and bypassing what rules that would normally be in place elsewhere – that’s
a big giant question."

I think you mean that the compromised server can construct a CSID list such
that the packet it is sending as a reply would reach some part of the
network not normally accessible to its flows.   That's a little confusing
to me, because I thought your original view of the attack was that it could
construct a loop between the two systems.  I'm also a bit confused because
for this attack you'd seem to need both for the attacker to have access to
the information needed to do the steering and for the network to have
off-limits areas where the limits were not implemented using the same
system that steers packets through the network.  It's likely, though, that
I'm still not understanding the attack correctly.

regards,

Ted Hardie

On Thu, Oct 21, 2021 at 11:54 AM Andrew Alston <
[email-masked]> wrote:

> MPLS – is fail-closed.  The router itself – would need mpls explicitly
> enabled on the port facing the server to handle an mpls packet.
>
>
>
> In this case – its not the same thing – these are v6 packets – tey will
> flow – unless you explicitly access list every single port to every single
> host server.  Once you get a server on the network that does not have
> explicit filtering on the ingress port on the router – because of the
> de-encap that occurs automatically at the end of the csid list – you can
> shove whatever you want behind that – its gonna de-encap and its gonna
> forward.  What it forwards – to where – and bypassing what rules that would
> normally be in place elsewhere – that’s a big giant question.
>
>
>
> For example – BCP38 that says – do not allow a host to send into the
> network from addresses not assigned to it.  Except – the server itself is
> now sending from its own legitimate source address on the outer packet.
> You hit one sid – it de-encaps – and now – you got a packet that was
> encapsulated – de-encapsulated and floating around on the network – having
> bypassed the BCP38 filtering.
>
>
>
> You do not need access to the routers to do this – all you need to know is
> the Locator and a single SID on the network.
>
>
>
> Andrew
>
>
>
>
>
> *Sent:* Thursday, October 21, 2021 1:49 PM

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 21 Oct 2021 13:31:38 +0100

Ted Hardie wrote on 21/10/2021 12:16:
> It's likely, though, that I'm still not understanding the attack correctly.

the difference between mpls and srv6 in this regard is:

- a device outside an mpls core can only change the mpls label stack if 
their network port is explicitly enabled for mpls, which it won't be by 
default.  This applies to e.g. customer edge and third party connections.

- a device outside an SRv6 network core can construct SRv6 packets and 
inject them into the SRv6 core unless there are explicit packet filters 
in place on the SRv6 edge to stop them from doing this, which there 
won't be by default.

This is why RH0 was disabled by default.

Nick

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 21 Oct 2021 12:44:30 +0000

Hi Nick,
> - a device outside an SRv6 network core can construct SRv6 packets and inject them into the SRv6 core unless there are explicit packet filters in place on the SRv6 edge to stop them from doing this, which there won't be by default.

Why? All current SRRv6 specifications are talking that such filters should be by default.
draft-filsfilscheng-spring-srv6-srh-compression just reference that "we are too":
"The security requirements and mechanisms described in [RFC8402] and [RFC8754] also apply to this document".
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: Thursday, October 21, 2021 3:32 PM
To: Ted Hardie <[email-masked]>
Cc: [email-masked]
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

- a device outside an mpls core can only change the mpls label stack if their network port is explicitly enabled for mpls, which it won't be by default.  This applies to e.g. customer edge and third party connections.

- a device outside an SRv6 network core can construct SRv6 packets and inject them into the SRv6 core unless there are explicit packet filters in place on the SRv6 edge to stop them from doing this, which there won't be by default.

Nick

---

From: Ted Hardie <[email-masked]>
Date: Thu, 21 Oct 2021 13:44:14 +0100

Hi Andrew,

I appreciate the time you've taken to tease this out more.  Rather than
belavor it, I think both of the attacks you mention are already covered in
the Security Considerations section (8.2) of the architecture document (RFC
8402).

But I thoroughly agree with you that additional security review is always
valuable, and one of the good things about the IETF process is it gives a
formal way to solicit review from a competent directorate and confirm that
review by the relevant area directors at several points along the
process.   Assuming the documents are adopted, I think that will happen in
the normal course of events, and I look forward to reading the outcome of
the review.  I'm not a security guy, and it may be that there are
additional attacks not covered in RFC 8402, and it would be great to have
those identified.

regards,

Ted Hardie

On Thu, Oct 21, 2021 at 12:27 PM Andrew Alston <
[email-masked]> wrote:

> Separate attack vectors.
>
>
>
> The loop is one – the bypass of restrictions is another- and by the way –
> this stuff – isn’t just applicable to the compression mechanisms – its to
> srv6 itself.
>
>
>
> But – lets look at this from a compression perspective and let me see if I
> can unpack this a bit further.
>
>
>
> Lets say I have openstack running.
>
>
>
> I have a single VM on there – that wants to talk network programming
> straight to the network – it wants to be able to steer – so – on the port
> on the router – I have to permit ingress traffic with a DA of the locator
> block + sids. I could add something to say specific from a particular ipv6
> address – this presumes that the ipv6 source isn’t allocated by RA or other
> dynamic mechanism in a shared pool – else filtering that could be an issue.
>
>
>
> Now – another host behind the same port – has access to send to the same
> Locator + Sids.
>
>
>
> This host gets promised – and it decides – it wants to send evil packets
> from a source that isn’t its own to the outside world. It encaps the packet
> with an SRH – using its own source address – and sets the SID to the first
> sid in the network.
>
>
>
> This packet then arrives at that node – the last sid is reached – it
> deencaps.  The router then takes that deencapsulated packet – and forwards
> it using the standard FIB – and you just bypassed BCP38 – because you’ve
> walked past the ingress filtering by using your original source – you’ve
> walked past the normal destination filtering because of the shared nature
> of this – and you’ve used the encapsulated packet – which is deencapsulated
> when the last sid is hit – as your attacking packet.
>
>
>
> That’s as I said a theoretical attack – and I’m pretty sure there are more
> if we get a little creative.
>
>
>
> My point here is – we probably need to step back – and have security area
> take a very very very close look at all of this, because we introduce some
> very nasty issues.
>
>
>
> Andrew
>
>
>
> *Sent:* Thursday, October 21, 2021 2:17 PM
> I think you mean that the compromised server can construct a CSID list
> such that the packet it is sending as a reply would reach some part of the

---

From: Andrew Alston <[email-masked]>
Date: Thu, 21 Oct 2021 12:50:18 +0000

The difference here is that in an mpls environment - your default on a port is to "fail-closed"  if you don't explicitly enable mpls - the packets don't flow.  In an SRv6 work - that's not the case - because you're dealing with normal addresses.

I'd like to know what the effect on tcams are if you apply explicit ip filters to every single port.

Let me put this another way as someone pointed out to me - you don't go and enable ISIS on every port on the router just in case - you enable it when its needed and where it's needed - again - by default - its "fail-closed"

That's the major difference here

Andrew

From: ipv6 <[email-masked]> On Behalf Of Vasilenko Eduard
Sent: Thursday, October 21, 2021 3:45 PM
To: Nick Hilliard <[email-masked]>; Ted Hardie <[email-masked]>
Cc: [email-masked]
Subject: RE: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Hi Nick,

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: Thursday, October 21, 2021 3:32 PM
To: Ted Hardie <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Nick

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 21 Oct 2021 13:07:56 +0000

Hi Andrew,
The problem that filters are needed by default on the domain border applies to all 6 solutions for CSID that were in discussion at different times.
It does not matter what type of Enhanced Header would be used, all EHs are assumed accepted by default for IPv6 transit traffic.
Unfortunately, we know that it is working now on the wide scale (well proved) because there were many discussions here of how many headers are blocked by different carriers on the Internet and how to stop this practice:(
What do you propose instead? I do not remember any proposition that is not using IPv6 EH.
Eduard
From: Andrew Alston [mailto:[email-masked]]
Sent: Thursday, October 21, 2021 3:50 PM
To: Vasilenko Eduard <[email-masked]>; Nick Hilliard <[email-masked]>; Ted Hardie <[email-masked]>
Cc: [email-masked]
Subject: RE: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Andrew

To: Nick Hilliard <[email-masked]<mailto:[email-masked]>>; Ted Hardie <[email-masked]<mailto:[email-masked]>>

Hi Nick,

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Nick Hilliard
Sent: Thursday, October 21, 2021 3:32 PM
To: Ted Hardie <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

Nick

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 Oct 2021 09:38:50 -0700

On Thu, Oct 21, 2021 at 6:08 AM Vasilenko Eduard
<[email-masked]> wrote:
> Unfortunately, we know that it is working now on the wide scale (well proved) because there were many discussions here of how many headers are blocked by different carriers on the Internet and how to stop this practiceL
>
Eduard,

I'm missing some things. The draft is about compressing the SID list
of an SRH. I assume this means that the SRH is only compressed and not
entirely removed. It that true? Also, when an intermediate node is
processing  a packet as SRv6, determination of the next hop is made
solely by processing the routing header (not just the IP destination
address). Is that true? And what is DA in the draft? I see no
definition of this before its use in the draft.

If the idea is that SRv6 packet are sent without an SRH where the
processing is sole based on destination address, and especially if
this is done as some sort of workaround for intermediate nodes that
drop EH, then I think there will be objections.

Tom

> The difference here is that in an mpls environment – your default on a port is to “fail-closed”  if you don’t explicitly enable mpls – the packets don’t flow.  In an SRv6 work – that’s not the case – because you’re dealing with normal addresses.
>
>
>
> I’d like to know what the effect on tcams are if you apply explicit ip filters to every single port.
>
>
>
> Let me put this another way as someone pointed out to me – you don’t go and enable ISIS on every port on the router just in case – you enable it when its needed and where it’s needed – again – by default – its “fail-closed”
>
>
>
> That’s the major difference here
>
>
>
> Andrew
>
>
>
>
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 21 Oct 2021 17:11:19 +0000

Hi Tom,
I believe that whatever is in DA, RH is attached, or else it is not SRv6 (compressed or normal SRH).
Hence, yes, it was exactly my point a few times already that it is easy to understand what to filter on the domain border.
Eduard
-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Thursday, October 21, 2021 7:39 PM
To: Vasilenko Eduard <[email-masked]>
Cc: Andrew Alston <[email-masked]>; Nick Hilliard <[email-masked]>; Ted Hardie <[email-masked]>; [email-masked]
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

On Thu, Oct 21, 2021 at 6:08 AM Vasilenko Eduard <[email-masked]> wrote:
> Unfortunately, we know that it is working now on the wide scale (well 
> proved) because there were many discussions here of how many headers 
> are blocked by different carriers on the Internet and how to stop this 
> practiceL
>
Eduard,

I'm missing some things. The draft is about compressing the SID list of an SRH. I assume this means that the SRH is only compressed and not entirely removed. It that true? Also, when an intermediate node is processing  a packet as SRv6, determination of the next hop is made solely by processing the routing header (not just the IP destination address). Is that true? And what is DA in the draft? I see no definition of this before its use in the draft.

If the idea is that SRv6 packet are sent without an SRH where the processing is sole based on destination address, and especially if this is done as some sort of workaround for intermediate nodes that drop EH, then I think there will be objections.

Tom

> To: Vasilenko Eduard <[email-masked]>; Nick Hilliard 
> <[email-masked]>; Ted Hardie <[email-masked]>
> Cc: [email-masked]
> Subject: RE: Question from SPRING regarding 
> Subject: RE: Question from SPRING regarding

---

From: Tom Herbert <[email-masked]>
Date: Thu, 21 Oct 2021 10:32:41 -0700

Draft authors: I am fundamentally confused about the terminology being
used in this draft to the point it's difficult to understand what the
proposed algorithm is actually doing. For instance, here is the first
of use of "DA" in the draft:

S01. If (DA.Argument != 0) {
   S02.   If (IPv6 Hop Limit <= 1) {
   S03.     Send an ICMP Time Exceeded message to the Source Address,
              Code 0 (Hop limit exceeded in transit),
              interrupt packet processing and discard the packet.
   S04.   }
   S05.   Copy the value of DA.Argument into the bits [B..(B+A-1)]
            of the Destination Address.

Normally, one would think that DA stands for "destination address",
but then referring to DA.Argument doesn't make sense since an IPv6
address has no such structure and why would Destination Address be
spelled out later? If this is a new term or part of SRv6 specific
terminology it should be defined in the "Terminology" section.

Thanks,
Tom

---

From: "Darren Dukes (ddukes)" <[email-masked]>
Date: Fri, 22 Oct 2021 05:27:34 +0000

Hi Tom,

You may have sorted this out already.
If not please see inline [DD].

Darren

________________________________
From: ipv6 <[email-masked]> on behalf of Tom Herbert <[email-masked]>
Sent: Thursday, October 21, 2021 1:37 PM
To: Vasilenko Eduard
Cc: [email-masked]
Subject: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression

[DD] without diminishing the need for terminology text. I hope the following is helpful.

DA does refer to the contents of the dest addr field of the ipv6 header.
The pseudocode defines the processing of a locally instantiated SRv6 sid when the DA matches “a FIB entry that represents a locally instantiated SRv6 SID”(rfc8754 and rfc8986).
As such DA is an SRv6 SID that has an arguments field as described in rfc8986.

Hope this helps
  Darren
[\DD]

Thanks,
Tom

---

From: Stefano Salsano <[email-masked]>
Date: Sat, 23 Oct 2021 02:29:32 +0200

Hi Nick,

the draft recommends to use a single CSID length (16 bits for NEXT, 32 
bits for REPLACE), and if an operator also chooses a single block length 
it's very easy to provide the wireshark extensions to dissect all CSID 
containers in your domain

if an operator wants to combine CSIDs of different length, building the 
debug tools becomes more complex, but this actually depends on the 
specific choices and configurations

SRv6 is confined to an operator's domain, so an operator will have to 
debug SRv6 packets that have been created by nodes under the control of 
the operator and following the configuration choices of the operator

Stefano