Subject: Dumb question about routing headers

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 May 2020 09:05:28 +1200

Is a routing header whose final destination is a multicast address, but whose previous segments are all unicast, valid?

Regards
   Brian Carpenter

---

From: Mark Smith <[email-masked]>
Date: Mon, 25 May 2020 07:21:50 +1000

On Mon, 25 May 2020, 07:06 Brian E Carpenter, <[email-masked]>
wrote:

> Is a routing header whose final destination is a multicast address, but
> whose previous segments are all unicast, valid?
>

A related question is are multicast addresses within the list if hops to
visit valid?

I thought it might not be because you could create a worse version of the
RFC 5095 attack.

However, I think the multicast forwarding RPF check prevents that working,
so a multicast addresses anywhere in an RH set of hops could be valid.

Haven't thought of a use for it though.

Regards,
Mark.

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

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 24 May 2020 22:22:31 +0100

Brian E Carpenter wrote on 24/05/2020 22:05:
> Is a routing header whose final destination is a multicast address,
> but whose previous segments are all unicast, valid?

... or whose intermediate destinations are multicast addresses?

https://twitter.com/brenankeller/status/1068615953989087232

Nick

---

From: Gyan Mishra <[email-masked]>
Date: Sun, 24 May 2020 19:05:33 -0400

For the multicast data plane to build the multicast path during the RPF
check for source or shared tree bust be the same interface as the path
through which the unicast destination was learned for the source for ASM or
SSM source tree or RP for ASM shared tree.  If you had previous segments
that were unicast and then all of sudden at a multicast segment thrown in
it would be a recursion issue there the unicast RPF interface has to be set
uRIB present and then multicast mRIB would use the same interface for its
RPF check based on pim being enabled uRIB path.

That scenario would not work.  All segments have to be unicast segments.  I
believe this question came up on PGM draft WGLC in regards to RFC 8200.  I
think the address type on PGM was lose and not descriptive as it should be
but from a technical multicast perspective it’s not possible to interleave
multicast with unicast segments as RPF check would fail.

Gyan

On Sun, May 24, 2020 at 5:23 PM Nick Hilliard <[email-masked]> wrote:

> .... or whose intermediate destinations are multicast addresses?
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 03:54:23 +0000

Brian,

There is no rule against it, but we should probably consider the security implications.

                                                         Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Brian E Carpenter
Sent: Sunday, May 24, 2020 5:05 PM
To: 6man <[email-masked]>
Subject: Dumb question about routing headers

[External Email. Be cautious of content]

Regards
   Brian Carpenter

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!QeWLbL5s0LLasFjI9iCBUxk0DXwOMFEdQ5TehtsEPWB_zL_pz71UXxDaJPI5j8dE$
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 03:56:17 +0000

Inline.....

Juniper Business Use Only
From: ipv6 <[email-masked]> On Behalf Of Mark Smith
Sent: Sunday, May 24, 2020 5:22 PM
To: Brian E Carpenter <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Dumb question about routing headers

On Mon, 25 May 2020, 07:06 Brian E Carpenter, <[email-masked]<mailto:[email-masked]>> wrote:
Is a routing header whose final destination is a multicast address, but whose previous segments are all unicast, valid?

A related question is are multicast addresses within the list if hops to visit valid?

[RB] There is no rule against this, but there certainly should be!

I thought it might not be because you could create a worse version of the RFC 5095 attack.

However, I think the multicast forwarding RPF check prevents that working, so a multicast addresses anywhere in an RH set of hops could be valid.

Regards,
Mark.

Regards
   Brian Carpenter

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!TM3agGjJI6WbBACEwjhtyimfv81DQPvCiA79nz6PM0jBmaecM5b8V83xwn88fMXA$>
--------------------------------------------------------------------

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 03:58:31 +0000

Folks,

The CRH forbids this. I am thinking that it should also forbid multicast addressed in the final position.

                                                                  Ron

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Nick Hilliard
Sent: Sunday, May 24, 2020 5:23 PM
To: Brian E Carpenter <[email-masked]>
Cc: 6man <[email-masked]>
Subject: Re: Dumb question about routing headers

https://urldefense.com/v3/__https://twitter.com/brenankeller/status/1068615953989087232__;!!NEt6yMaO-gk!X8uLVpisi3vLMZRjvkcOTpMes7OlQl-55faWFe0PNJR-JlvUwhNZo7SwaUwL8Usj$

Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!X8uLVpisi3vLMZRjvkcOTpMes7OlQl-55faWFe0PNJR-JlvUwhNZo7SwaTpKlJe4$
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Tue, 26 May 2020 07:42:25 +1000

Hi Ron,

On Mon, 25 May 2020 at 13:56, Ron Bonica <[email-masked]> wrote:
> Inline…..
<snip>
> [RB] There is no rule against this, but there certainly should be!

While I can't think of a use for multicast addresses in a source
route, I don't think we should prohibit it yet without more thought.
The multicast source address RPF check during multicast forwarding
prevents multicast packets being sent back towards where they came
from, so I don't think a forwarding loop using multicast addresses can
be formed, even if specified in the routing header.

If source address RPF checks were also universally performed for
unicast packets at each forwarding point then I don't think the RFC
5095 attack could have occurred either, because the attack involves
creating a path where packets are sent back towards where they came
from, creating the forwarding loop.

Regards,
Mark.

<snip>

---

From: Ron Bonica <[email-masked]>
Date: Mon, 25 May 2020 21:55:58 +0000

Mark,

There might be a use-case for the following Routing header:

- 1st destination: unicast
- 2nd destination: unicast
- final destination: multicast

But the following Routing header might be used as a DoS attack against the final destination:

- 1st destination: unicast
- 2nd destination: multicast
- final destination: unicast

The source sends a single packet. The final destination receives one copy of that packet from each member of the multicast group.

                                                                                     Ron

-----Original Message-----
From: Mark Smith <[email-masked]> 
Sent: Monday, May 25, 2020 5:42 PM
To: Ron Bonica <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>; 6man <[email-masked]>
Subject: Re: Dumb question about routing headers

Hi Ron,

<snip>
> [RB] There is no rule against this, but there certainly should be!

While I can't think of a use for multicast addresses in a source route, I don't think we should prohibit it yet without more thought.
The multicast source address RPF check during multicast forwarding prevents multicast packets being sent back towards where they came from, so I don't think a forwarding loop using multicast addresses can be formed, even if specified in the routing header.

If source address RPF checks were also universally performed for unicast packets at each forwarding point then I don't think the RFC
5095 attack could have occurred either, because the attack involves creating a path where packets are sent back towards where they came from, creating the forwarding loop.

Regards,
Mark.

<snip>

---

From: Jeff Tantsura <[email-masked]>
Date: Mon, 25 May 2020 14:59:06 -0700

Mark,

RPF has to be performed against an unicast address, one could use a somewhat hackish solutions ala RFC5496 though.
uRPF (RFC3704) is a commonly used technique to prevent packets to enter a router on a wrong interface (spoofed).

Cheers,
Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 May 2020 00:06:19 +0200

Hello Ron,

Your example with 2nd dst being a multicast illustrates a very legitimate
use case for Quic protocol robust delivery or for that matter even TCP
across geo-diverse transit sites. Of course one's application needs to be
upgraded to support such arbitration but this is not a big issue.

What you call (D)DoS I would call real time data delivery resilience.

Thank you very much,
Robert.

On Mon, May 25, 2020 at 11:56 PM Ron Bonica <rbonica=
[email-masked]> wrote:

> The source sends a single packet. The final destination receives one copy
> of that packet from each member of the multicast group.
>
>
>            Ron
>
>
>
> While I can't think of a use for multicast addresses in a source route, I
> don't think we should prohibit it yet without more thought.
> prevents multicast packets being sent back towards where they came from, so
> I don't think a forwarding loop using multicast addresses can be formed,
> even if specified in the routing header.
>
> If source address RPF checks were also universally performed for unicast
> packets at each forwarding point then I don't think the RFC
> creating a path where packets are sent back towards where they came from,
> creating the forwarding loop.
>
> Regards,
> Mark.
>
>
> <snip>