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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Robert

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

Keep safe,

Pascal

> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Tom Herbert
> Sent: dimanche 10 mai 2020 23:10
> To: Robert Raszuk <[e-mail]>
> Cc: 6man WG <[e-mail]>
> Subject: Re: Packets leaking and escaping from domains ....
> 
> On Sun, May 10, 2020 at 8:39 AM Robert Raszuk <[e-mail]> 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.
> >
> > I think facts as documented in current deployments actually prove
> > otherwise:
> > https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-st
> > atus-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.
> >
> 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.
> >
> >
> > On Sun, May 10, 2020 at 5:13 PM Tom Herbert <[e-mail]>
> wrote:
> >>
> >> On Sun, May 10, 2020 at 4:17 AM Robert Raszuk <[e-mail]>
> wrote:
> >> >
> >> >
> >> >> 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.
> >> >
> >> > 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
> >>
> >> > One would hope at least we all agree on that ....
> >> >
> >> >
> >> > -------------------------------------------------------------------
> >> > - IETF IPv6 working group mailing list [e-mail] Administrative
> >> > Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> > -------------------------------------------------------------------
> >> > -
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------