Subject: Packets leaking and escaping from domains ....

From: Robert Raszuk <[email-masked]>
Date: Sun, 10 May 2020 11:36:31 +0200

All,

Lecture of Mark's example inspired this note. He said:

*> If controlled domains were as reliability deployed as some believe, *
*> we wouldn't have RFC1918 address leaks, 100.64/10 route leaks,  *

First let's observe that data packets usually travel in the data plane and
above seems to be a control plane incident.
Those are two completely different things.

IP packets go where routing points it to go. So what some call leaking or
escaping others call interdomain routing. In my books interdomain routing
is rather a good thing.

If I am running SRv6 between 100s of my enterprise sites and I happen to
interconnect them over Internet with my choice of an encapsulation if I put
as destination address a remote site I rather do want it to leak outside of
my site A to reach site B. That is real value of IPv4 or IPv6.

Putting aside many MPLS drawbacks (some of them were very well enumerated
by Jingrong) the major benefit of SRv6 is actually seamless compatibility
with legacy nodes which do not support any new encapsulation.

Last if packet escapes (say based on the default route) if there is no
route to the destination it will be dropped. If there is route it will be
hopefully delivered. As simple as this.

I hope this should put to rest this pretty nonsense fear that those wild
and norty packets will start escaping and running away of a given domain
the moment they see SRH inside them.

Many thx,
R.

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 May 2020 20:36:07 +1000

> above seems to be a control plane incident.

They demonstrate that supposed "perfect" controlled or limited domains,
attached to the Internet, whether data or control plane, are not the
reality being asserted in some RFCs and IDs.

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

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 10 May 2020 12:11:58 +0100

Robert Raszuk wrote on 10/05/2020 10:36:
> Putting aside many MPLS drawbacks (some of them were very well 
> enumerated by Jingrong) the major benefit of SRv6 is actually seamless 
> compatibility with legacy nodes which do not support any new encapsulation.

this is the heart of what we're talking about: the current proposal on 
the table is not compatible with legacy nodes.

Nick

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 10 May 2020 13:16:25 +0200

> the table is not compatible with legacy nodes.

Of course it is.

For non SR capable IPv6 transit nodes not acting as SR segment endpoints
all they see is a plain IPv6 packet.

One would hope at least we all agree on that ....

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 10 May 2020 12:21:27 +0100

> all they see is a plain IPv6 packet.

You're saying this like a couple of months discussion about the issues 
with rfc8200 never happened.

Enjoy your Sunday afternoon - I will enjoy mine too!

Nick

---

From: Tom Herbert <[email-masked]>
Date: Sun, 10 May 2020 08:13:42 -0700

On Sun, May 10, 2020 at 4:17 AM Robert Raszuk <[email-masked]> wrote:
> For non SR capable IPv6 transit nodes not acting as SR segment endpoints all they see is a plain IPv6 packet.
>

Robert,

You seem to be assuming that non-SR node will just ignore an inserted
header; we know that isn't always true. There will be a fair number of
routers or hosts that will drop packets with a segment routing
extension header (like described in RFC7872). A limited domain doesn't
guarantee this issue goes away. So a problem occurs when the inserted
header causes loss or corruptions at any downstream node irrespective
of whether the downstream router supports SR. When this happens there
is no feedback loop to the node inserting headers that it is causing
harm. The source host might detect packets are being lost or might
even get an ICMP error, but in either case it cannot take any action
to rectify the problem since it's not the one causing the problem and
they will have no idea as to who that might be. Even if the network
operator does notice some node dropping packets, they still would need
to reverse engineer who inserted the headers which requires more than
just looking at the packet and might not be a simple exercise
escpecially if the packet has crossed domains.

I believe this is a fundamental problem and it violates the sending
clause of the robustness principle.  Attribution of packet contents is
critical and RFC8200 is very clear that the source host "owns" the
IPv6 headers and is specific about the conditions that intermediate
nodes are allowed to modify packets in transit. This is the motivation
for draft-herbert-6man-eh-attrib-00, packets with inserted headers
would at least include an indicate of what exactly has been inserted
and who the responsible party is.

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 10 May 2020 17:39:08 +0200

Hi Tom,

The problems described by RFC7872 do not talk about IPv6 bugs and drops due
to presence of Routing Headers.

I think we have heard so many times that RHs MUST not be processed by
transit nodes - nodes which DA address is not in the DA of the packet.

So here you are stating that there is another fear that routers will drop a
IPv6 packet if it contains Routing Header of some sort. Worse sender for
some reason will not know about it.

I think facts as documented in current deployments actually prove
otherwise:
https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-04

I am yet to see a single prove that not a final destinations neither
segment endpoints just drop IPv6 transit packets if it contains single SRH
(or for that matter even multiple SRHs legally or illegally inserted). Till
then let's assume that IPv6 actually works both in the Internet as well as
in private domains.

Many thx,
Robert.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 May 2020 09:08:17 +1200

On 11-May-20 03:39, Robert Raszuk wrote:
> Hi Tom,
> 
> The problems described by RFC7872 do not talk about IPv6 bugs and drops due to presence of Routing Headers.. 
> 
> I think we have heard so many times that RHs MUST not be processed by transit nodes - nodes which DA address is not in the DA of the packet. 
> 
> So here you are stating that there is another fear that routers will drop a IPv6 packet if it contains Routing Header of some sort. Worse sender for some reason will not know about it. 

It's as if we never wrote https://tools.ietf.org/html/rfc7045#section-1

The Internet is not transparent to extension headers; still less is it transparent to new routing header types unknown by old boxes.

I agree with you that the worst consequence is dropped packets, if they leak. But debugging connection failures of this kind is essentially impossible and can drive users and help desks crazy. Who is inserting an SRH in my packet and then sending it on to the outside world? Where is the tiny configuration error that causes this? (Maybe there's a corner case bug in the PSP code?)

That's why the ecapsulation model is fundamentally better; it limits the problem to the encap/decap tunnel by construction, and leaked SRHs simply cannot happen.

   Brian

> I think facts as documented in current deployments actually prove otherwise: https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-04
> 
> I am yet to see a single prove that not a final destinations neither segment endpoints just drop IPv6 transit packets if it contains single SRH (or for that matter even multiple SRHs legally or illegally inserted). Till then let's assume that IPv6 actually works both in the Internet as well as in private domains. 
> 
> Many thx,
> Robert.
> 
> 
> On Sun, May 10, 2020 at 5:13 PM Tom Herbert <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     On Sun, May 10, 2020 at 4:17 AM Robert Raszuk <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     >
>     > [email-masked] <mailto:[email-masked]>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 10 May 2020 14:10:01 -0700

On Sun, May 10, 2020 at 8:39 AM Robert Raszuk <[email-masked]> wrote:
>
> Hi Tom,
>
> The problems described by RFC7872 do not talk about IPv6 bugs and drops due to presence of Routing Headers.
>
Robert,

Except that neither IPv6 nor SRv6, nor any reasonable IETF protocol
for that matter, ever make the assumption that protocols "just work".
In the real world there are various conditions and that's why we need
error reporting, like from ICMP, and error handling. For instance,
RFC8754 prescribes sending of ICMP errors in response to errors about
the SRH. That RFC is also very clear that the ICMP error is sent to
the source address of that packet. So if an ICMP error is sent for a
packet that contains an inserted header, the error goes to the
original source of the packet not to the node that inserted the
header. That begs the obvious question: how is a host receiving the
error supposed to process an ICMP error containing headers that it
didn't actually send. For instance, if the ICMP error indicates a
parameter problem in the inserted header what is the host supposed to
do with that? Is there a way to signal the network that it's doing
something wrong? What if it's a PTB message but the host path MTU is
already 1280 for a path?

Please note, I am specifically asking for the normative requirements
of the protocol being defined, just saying there's deployment and you
haven't seen any problems so far isn't sufficient.

Tom

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 11 May 2020 00:05:11 +0200

Hi Tom,

While I admit that current network diagnostic tools commonly used are from
a stone ages what you are asking is very reasonable.

Specifically when a node inserts a SRH without encapsulating the packet
again IMO it would be very reasonable ask to mandate that original src is
placed into SRH and given's node src is placed in SA of the outer IP
header.

When SRH get's removed original source address returns to its place.

And that should be applicable regardless if it is happening inside a domain
which already encapsulated the packet and maybe already inserted an SRH or
when the reason for SRH insertion (ex: TI-LFA) happens to be the only SR
function on the packet's path from original src to "final" destination.

FWIW I would be very supportive of such mandate.

Many thx,
R.

On Sun, May 10, 2020 at 11:10 PM Tom Herbert <[email-masked]> wrote:

> > So here you are stating that there is another fear that routers will
> drop a IPv6 packet if it contains Routing Header of some sort. Worse sender
> for some reason will not know about it.
> >
> >> > For non SR capable IPv6 transit nodes not acting as SR segment
> endpoints all they see is a plain IPv6 packet.
> >> >
> >>
> >> Robert,
> >>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 10 May 2020 16:31:46 -0700

On Sun, May 10, 2020, 3:05 PM Robert Raszuk <[email-masked]> wrote:

> And that should be applicable regardless if it is happening inside a
> domain which already encapsulated the packet and maybe already inserted an
> SRH or when the reason for SRH insertion (ex: TI-LFA) happens to be the
> only SR function on the packet's path from original src to "final"
> destination.
>

Robert,

Doing that will create new problems and complexity we need to worry about,
like trying to distinguish between ICMP errors that should go to the
intermediate node and those that go to the source. Instead of trying to
chase down and fix every adverse side effect of header insertion, why not
just encapsulate packets instead which is the simpler and well understood
approach?

Tom

---

From: "Manfredi (US), Albert E" <[email-masked]>
Date: Mon, 11 May 2020 00:47:21 +0000

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter

> That's why the ecapsulation model is fundamentally better; it limits the problem to the encap/decap tunnel by construction, and leaked SRHs simply cannot happen.

+1.

Following through the arguments pro and con, in this long thread, including arguments along the lines of what people do in the privacy of their own bedrooms. It's seems to be a case of someone doing something fundamentally funky, but wanting to get a blessing for doing so.

Why ask for a blessing? If a user is experiencing some inexplicable problem, and the user's network domain, or the destination's domain, are doing unnatural acts, the onus of debugging should fall immediately on that questionable practice.

There are other examples of individual companies creating their own proprietary tricks, without necessarily asking for a blessing. And yes, they do cause problems. Just look at the special, clever tricks, a long and diverse list, involved in IGMP snooping.

Bert

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 11 May 2020 08:28:12 +0000

Hello Robert

This requirement has similarities with the HoA in MIPv6, so indeed it appears feasible;

Keep safe,

Pascal

> From: ipv6 <[email-masked]> On Behalf Of Tom Herbert
> Sent: dimanche 10 mai 2020 23:10
> To: Robert Raszuk <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: Packets leaking and escaping from domains ....
> 
> IPv6 packet if it contains Routing Header of some sort. Worse sender for some
> reason will not know about it.
> >
> > I am yet to see a single prove that not a final destinations neither segment
> endpoints just drop IPv6 transit packets if it contains single SRH (or for that
> matter even multiple SRHs legally or illegally inserted). Till then let's assume
> that IPv6 actually works both in the Internet as well as in private domains.
> >
> Robert,
> 
> Except that neither IPv6 nor SRv6, nor any reasonable IETF protocol for that
> matter, ever make the assumption that protocols "just work".
> In the real world there are various conditions and that's why we need error
> reporting, like from ICMP, and error handling. For instance,
> RFC8754 prescribes sending of ICMP errors in response to errors about the
> SRH. That RFC is also very clear that the ICMP error is sent to the source
> address of that packet. So if an ICMP error is sent for a packet that contains an
> inserted header, the error goes to the original source of the packet not to the
> node that inserted the header. That begs the obvious question: how is a host
> receiving the error supposed to process an ICMP error containing headers that
> it didn't actually send. For instance, if the ICMP error indicates a parameter
> problem in the inserted header what is the host supposed to do with that? Is
> there a way to signal the network that it's doing something wrong? What if it's
> a PTB message but the host path MTU is already 1280 for a path?
> 
> Please note, I am specifically asking for the normative requirements of the
> protocol being defined, just saying there's deployment and you haven't seen
> any problems so far isn't sufficient.
> 
> Tom
> 
> > Many thx,
> > Robert.
> >
> >
> >> >> this is the heart of what we're talking about: the current
> >> >> proposal on the table is not compatible with legacy nodes.
> >> >
> >> >
> >> > Of course it is.
> >> >
> >> header; we know that isn't always true. There will be a fair number
> >> of routers or hosts that will drop packets with a segment routing
> >> extension header (like described in RFC7872). A limited domain
> >> doesn't guarantee this issue goes away. So a problem occurs when the
> >> inserted header causes loss or corruptions at any downstream node
> >> irrespective of whether the downstream router supports SR. When this
> >> happens there is no feedback loop to the node inserting headers that
> >> it is causing harm. The source host might detect packets are being
> >> lost or might even get an ICMP error, but in either case it cannot
> >> take any action to rectify the problem since it's not the one causing
> >> the problem and they will have no idea as to who that might be. Even
> >> if the network operator does notice some node dropping packets, they
> >> still would need to reverse engineer who inserted the headers which
> >> requires more than just looking at the packet and might not be a
> >> simple exercise escpecially if the packet has crossed domains.
> >>
> >> clause of the robustness principle.  Attribution of packet contents
> >> is critical and RFC8200 is very clear that the source host "owns" the
> >> nodes are allowed to modify packets in transit. This is the
> >> motivation for draft-herbert-6man-eh-attrib-00, packets with inserted
> >> headers would at least include an indicate of what exactly has been
> >> inserted and who the responsible party is.
> >>
> >> Tom
> >>
> >> > -------------------------------------------------------------------
> >> > - IETF IPv6 working group mailing list [email-masked] Administrative
> >> > Requests: https://www.ietf.org/mailman/listinfo/ipv6