Subject: Robustness principle and multicast source address

From: Jen Linkova <[email-masked]>
Date: Thu, 15 Nov 2018 17:31:31 +1100

The section 2.7 of RFC4921 says:

Multicast addresses must not be used as source addresses in IPv6
packets or appear in any Routing header.

(https://tools.ietf.org/html/rfc4291#section-2.7)

Does it mean that any packets with multicast source MUST be dropped by
the receiver? Or shall Postel's Law still apply?

In particular (practical question...): shall an NA packet from the
multicast source be dropped (if one applies the NA validation rules
from https://tools.ietf.org/html/rfc4861#section-7.1.2 such packet
would be still a valid advertisement...)

-- 
SY, Jen Linkova aka Furry

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Thu, 15 Nov 2018 08:56:28 +0100

Hi Jen,

> the receiver? Or shall Postel's Law still apply?

IMHO, applying Postel's law would mean to be prepared receiving such a
packet, but to ignore it. Processing it may cause problems...

> would be still a valid advertisement...)

I would say yes, because such a packet should have never been sent
according to the current specs. This would allow the test of the broken
implementation to discover that something is not working and probably
get the code fixed...

Regards
 Roland

---

From: Yu Tianpeng <[email-masked]>
Date: Thu, 15 Nov 2018 12:07:35 +0000

Hi,
My POV, the definition in 4921 suits for all ipv6 protocol, validation of
source IP should have been done before validation of NA.
Regards,
Tim

On Thu, 15 Nov 2018, 07:56 Bless, Roland (TM) <[email-masked] wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Nov 2018 08:28:08 +1300

I'm not a big fan of draft-iab-protocol-maintenance ("The Harmful
Consequences of the Robustness Principle") but in this case I
think it applies. Such a packet is so clearly wrong that it
should be dropped. (Whether it should be logged or reported is
another question.)

Regards
   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 15 Nov 2018 20:38:51 +0100

On Nov 15, 2018, at 07:31, Jen Linkova <[email-masked]> wrote:
> the receiver? Or shall Postel’s Law still apply?

Postel’s robustness principle sure applies:

be conservative in what you do[…]

(Section 2.10 of RFC 793.)

Specifically, since the case is expressly prohibited, an implementation not honoring the above cannot assume that other implementations will do something useful or expected with the packet.  (The misunderstanding of Postel’s principle that causes protocols to turn into soup is based on ignoring its onus on the sender to be conservative.)

Grüße, Carsten

---

From: Jen Linkova <[email-masked]>
Date: Mon, 19 Nov 2018 12:25:06 +1100

> packet, but to ignore it. Processing it may cause problems...

You are right, there is a difference between 'being able to receive'
and 'process'.
Thanks for your comment!

> implementation to discover that something is not working and probably

That's what I've been thinking...

---

From: Jen Linkova <[email-masked]>
Date: Mon, 19 Nov 2018 15:26:46 +1100

Hi Brian,

On Fri, Nov 16, 2018 at 6:28 AM Brian E Carpenter
<[email-masked]> wrote:
> should be dropped.

I totally agree.
Not sure if it's so clear to router vendors...;(

---

From: Mark Smith <[email-masked]>
Date: Tue, 20 Nov 2018 12:45:11 +1100

Hi Jen,

> the receiver? Or shall Postel's Law still apply?

I'd be saying MUST, and silently.

A multicast source address fundamentally doesn't really make sense. A
multicast address represents a group of addresses, so a multicast
address in a single packet's source address field suggests the single
packet somehow has multiple sources, which suggests multiple devices
built parts of the single packet. IPv6 doesn't support multi-source
multi-part single packets! (Has any protocol?)

Source addresses are also commonly used as destination addresses for
responses, so a multicast source address where a unicast address
should be can mean a link layer flooded multicast instead of unicast
response. (For IPv4, RFC1122 specifies that received, link-layer
broadcast IPv4 packets that do not have an IPv4 broadcast or multicast
address should be silently ignored, mitigating this scenario.)

With old enough Ethernet switch firmware that supports translational
bridging, the I/G bit in the Ethernet source address field actually
means there is a source route information field, following the
destination address
(https://www.cisco.com/c/en/us/support/docs/ibm-technologies/token-ring/24501-trb-rif.html).
If there isn't, the switch might drop the packet, which some server
colleagues of mine found out when they tried to use the Linux IPtables
ClusterIP extension, as it tries to use "multicast" source Ethernet
addresses.

> would be still a valid advertisement...)

This draft did specify some more stringent NA source address
validation, as well as other validation e.g. Source Link Layer Address
option does not contain a multicast link layer address.

"Security Assessment of Neighbor Discovery (ND) for IPv6"
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-nd-security-00

Regards,
Mark.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 19 Nov 2018 17:58:14 -0800

> I'd be saying MUST, and silently.

An interesting practical use of a multicast address as a source address
is to engage in a smurf attack. Multicast sourced packets go to the
target. Target replies go to multicast address. Replies to that come
back to the original target with great amplification.

And yes, I know, in theory nodes will not send ICMPv6 in response to a
packet received through a multicast address. But in practice, who knows?
Silence is golden.

-- Christian Huitema

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 30 Nov 2018 12:05:26 +0100

> multi-part single packets! (Has any protocol?)

Not yet, but why not.

This idea of a packet coming from we dont know where and sent to many 
others could be useful.

I routinely look at packets without caring where they come from.

Many routers forward packets without carying where they come from.

So instead of being useless, maybe call it useless.  That could be a 
specific address, like "usel:ess::"

In vehicular networking the broadcast of PoI has this kind of absence of 
precision: when one receives a PoI one just learns that in that area 
(dont know precisely where, no src) there is an important point like a 
gas station.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 30 Nov 2018 12:05:49 +0100

> packets or appear in any Routing header.

Jen,

There is no such restrictions for link-layer addresses like IEEE MAC 
addresses.

Since there is a very tight relationship between IP and MAC, whose rule 
should prevail?  IP's or MAC's?

I am asking because I was just been pointed by a fellow IETFer (to whom 
I thank very much) to a link-layer message send from a broadcast address 
to another broadcast address.  It's been captured between cars and RSUs, 
probably in America.  URL available upon request.

Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 30 Nov 2018 23:37:48 +1100

> This idea of a packet coming from we dont know where and sent to many

So the above is about a multi-source, multi-part packet, that is at some
point and at some place combined into a single packet, rather than a single
packet originated by an unimportant and unspecified source.

(For unidirectional communication, the source address is optional, in the
sense that because there will be no reply, the actual source device's
address is not essential, although it may be useful.)

> specific address, like "usel:ess::"

::0, the unspecified address, is the source address you're looking for.

> > (
> https://www.cisco.com/c/en/us/support/docs/ibm-technologies/token-ring/24501-trb-rif.html
> ).

---

From: Ola Thoresen <[email-masked]>
Date: Fri, 30 Nov 2018 13:47:26 +0100

On 30.11.2018 13:37, Mark Smith wrote:

>
>
> On Fri., 30 Nov. 2018, 22:05 Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]> wrote:
>
>
>     >
>     > A multicast source address fundamentally doesn't really make
>     sense.. A
> So the above is about a multi-source, multi-part packet, that is at 
> some point and at some place combined into a single packet, rather 
> than a single packet originated by an unimportant and unspecified source.
>

I do see a potential use case here, but I have not really investigated 
if there could be something I have overlooked.

Let's say I create a stateless service that can be served by multiple 
instances, but that is "optional", and not searched for by hosts by 
default.  I then give this service a multicast-address where it can be 
reached.  But I also want to announce the presence of said service to 
either a group of hosts (eg. "All routers" or whatever) or to "All 
hosts".  It _could_ then make sense to send a packet with SOURCE - 
my:service:multicast:address and DESTINATION - 
all:routers:multicast:address to inform the routers that my service is 
now available.

Not that it is viable today, but in the future maybe?

/Ola (T)

---

From: Fernando Gont <[email-masked]>
Date: Fri, 30 Nov 2018 10:21:15 -0300

> Not that it is viable today, but in the future maybe?

In general, if you allow packets to employ a multicast source address
(as well as a dst multicast address, of course), that would seem to me
as potnetially exploitable (sooner or later), for packet storms and
amplification.

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 30 Nov 2018 14:17:53 +0000

Sent by Alexander:

It looks like this use case is “among vehicle-based devices, and between fixed roadside devices and vehicle-based devices using the 5.9 GHz Dedicated Short Range Communications/Wireless Access in Vehicular Environments (DSRC/WAVE) mode” *

In other words, things that are really close by and capable of receiving the very local wireless transmission. There’s no expectation of packet storms or amplification, because it’s not an “Internet” use case.

Barbara

* https://standards.ieee.org/standard/1609_3-2016.html

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 30 Nov 2018 16:08:09 +0100

Le 30/11/2018 à 13:37, Mark Smith a écrit :
>      > On Thu, 15 Nov 2018 at 17:32, Jen Linkova <[email-masked]
>     <mailto:[email-masked]>> wrote:
> point and at some place combined into a single packet, rather than a 
> single packet originated by an unimportant and unspecified source.
> 
> (For unidirectional communication, the source address is optional, in 
> the sense that because there will be no reply, the actual source 
> device's address is not essential, although it may be useful.)
> 
> 

Sounds better indeed.

But it does not map in a corresponding MAC address :-(

Alex

>      >> [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Dec 2018 14:43:07 +1100

On Fri, 30 Nov 2018 at 23:49, Ola Thoresen <[email-masked]> wrote:
> On Fri., 30 Nov. 2018, 22:05 Alexandre Petrescu <[email-masked] wrote:
>>
>>
>> >
>> > A multicast source address fundamentally doesn't really make sense.. A
> So the above is about a multi-source, multi-part packet, that is at some point and at some place combined into a single packet, rather than a single packet originated by an unimportant and unspecified source.
>
>
>
> I do see a potential use case here, but I have not really investigated if there could be something I have overlooked.
>
> Let's say I create a stateless service that can be served by multiple instances,
> but that is "optional", and not searched for by hosts by default.  I then give this service a multicast-address where it can be reached.  But I also want to announce the presence of said service to either a group of hosts (eg. "All routers" or whatever) or to "All hosts".  It _could_ then make sense to send a packet with SOURCE - my:service:multicast:address and DESTINATION - all:routers:multicast:address to inform the routers that my service is now available.
>

Don't understand the use case well enough.

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Dec 2018 14:53:00 +1100

> But it does not map in a corresponding MAC address :-(

Don't understand the problem you're trying to solve.

If you want an IPv6 source address that maps to a unique MAC address,
you can't use an unspecified / not stated source address.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Dec 2018 15:38:19 +1100

> There is no such restrictions for link-layer addresses like IEEE MAC

Which specific IEEE spec are you working with?

I'm asking because

"IEEE Standard for Local and
Metropolitan Area Networks:
Overview and Architecture"

2014 edition says, in section 8.2.2, "Assignment of universal addresses"

"The I/G address bit is used to identify the destination MAC address as an
individual MAC address or a group
MAC address."

and in then in the diagram above that text, says the bit is "Application
dependent: e.g., I/G bit in addresses, M bit in protocol IDs".

It doesn't mention anything about the meaning of that bit in the source
address. If it had the same meaning in the source address field, it would
say that.

Specific to "Ethernet", In 802.3 2012 edition,

"3.2.4 Destination Address field
The Destination Address field specifies the station(s) for which the MAC
frame is intended. It may be an
individual or multicast (including broadcast) address.

3.2.5 Source Address field
The Source Address field specifies the station sending the MAC frame. The
Source Address field is not
interpreted by the MAC sublayer."

So the "I/G" bit being set in a source address is either invalid, or means
something specific to the IEEE protocol being used (I'm aware that it means
there is a Route Information field after the MAC header when using
transnational bridging between Token Ring/802.5 and Ethernet/802.3)

It may be possible that the below packet is valid, however that would mean
that the packet capture application is not correctly showing what the I/G
bit means.

Regards,
Mark.

> I am asking because I was just been pointed by a fellow IETFer (to whom I
> thank very much) to a link-layer message send from a broadcast address to
> another broadcast address.  It's been captured between cars and RSUs,
Alex