Do IGMPv3 enabled hosts block packets that have a different source?

[Mitrixsen]

Hello, everyone.

When the IGMPv3 receiver specifies the source that it wants to receive the multicast stream from, will the receiver also accept the multicast stream if it comes from a different source? For ex:

R6 has a completely different IP address than the source specified on the RECEIVER yet the RECEIVER still accepts the ping packet and responds back. I thought such packets wouldn't be accepted by the host? Is this the normal operation?

Thank you.
David

[M02@rt37]

Hello David,

If IGMPv3 SSM is correctly implemented, the receiver should only accept multicast traffic from the specified source.

If it still receives packets from an unexpected source (like routeur R6 in your topology), the issue is likely that PIM is not enforcing SSM correctly. So, please ensure that SSM is configured properly on R6 interface Gi0/1.

interface gig 0/1
ip pim sparse-mode

--

and under configure terminal:

ip multicast-routing
ip pim ssm range 232.0.0.0 255.255.255.0

[Joseph W. Doherty]

---

M02@rt37 wrote:

If IGMPv3 SSM is correctly implemented, . . .

If it still receives packets from an unexpected source (like routeur R6 in your topology), the issue is likely that PIM is not enforcing SSM correctly. So, please ensure that SSM is configured properly on R6 interface Gi0/1.

---

Possibly one or both are true.  Can't say for sure as I haven't studied SSM to that degree, and perhaps ditto for IGMP snooping too, to know what multicast should be sent to the host.

---

M02@rt37 wrote:

. . . the receiver should only accept multicast traffic from the specified source.

---

That's possibly debatable.  We need to distinguish between the receiver, as the host itself, and the particular APP that wants the SSM stream.  I don't know whether there's any standard that truly defines a packet delivered to the host must be dropped by the host (itself), if the host can "know" no APP requested that particular packet with (all) its "addressing".

I'll go into that further, in reply to David, in an hour or two from now.

[M02@rt37]

In strict IGMPv3 SSM, the expectation is that the network (PIM routers and IGMP snooping switches) should filter out multicast traffic from unwanted sources before it reaches the receiver. However, if that filtering isn't strictly enforced, the host’s network stack may still receive the packet, leaving it up to the application to discard it.

Agree with @Giuseppe Larosa, a router using ip igmp static-group is not a true receiver—it just simulates IGMP joins and may still respond to pings from any source.

[Joseph W. Doherty]

---

M02@rt37 wrote:

In strict IGMPv3 SSM, the expectation is that the network (PIM routers and IGMP snooping switches) should filter out multicast traffic from unwanted sources before it reaches the receiver.

---

That would be nice but a potential problem is there's no real standard for IGMP snooping.  There's RFC 2541, which is informative, but not proposed as a standard.  The RFC, though, does discuss IGMP snooping issues.  So, possibly, such issues could explain why pinging the active SSM multicast address, not (?) from the source, were delievered.

Basically, David asked why the "host" responded to the pings.  That question also invokes the question why such packets were even delivered to the host.  As to why the "host" responded, might be, indeed, for the reason @Giuseppe Larosa mentioned, but it may be debatable whether a host should NOT have processed the pings.

---

M02@rt37 wrote:

However, if that filtering isn't strictly enforced, the host’s network stack may still receive the packet, leaving it up to the application to discard it.

---

Exactly the point, I'm going to discuss next, in a reply to David.

[Harold Ritter · Accepted solution]

Hi @Joseph W. Doherty ,

> Basically, David asked why the "host" responded to the pings. 

As you mentioned, I think it would be up to the application to reject packet not sourced from the address specified in the igmpv3 configuration on that receiver. From an implementation point of view, IOS used as a host probably does not imposed any such restriction on the source of the multicast stream and just reply to the ping.

> That question also invokes the question why such packets were even delivered to the host.

The ping is being sourced from the last hop router (LHR). The LHR is not acting as a multicast router in this case, but as a multicast sender, which means it will send the multicast stream to all connected interfaces, including the one connected to the receiver.

If the packet was sent from a source that is not one of the multicast routers, the packet with a source different then the one configured on the receiver would be dropped by the multicast routers, as there would be no (S,G) for that specific stream. 

[Joseph W. Doherty]

@Harold Ritter very nice.  Didn't see this until after I posted by prior reply.

"From an implementation point of view, IOS used as a host probably does imposed any such restriction on the source of the multicast stream and just reply to the ping."

did you mean: ". . . does NOT impose . . ."?

"The LHR is not acting as a multicast router in this case, but as a multicast sender, which means it will send the multicast stream to all multicast enabled interfaces, including the one connected to the receiver."

Ah, duh, that nails it.  I.e. R6 effectively becomes another source for "232.0.0.1".

Or, changing the ping's source IP on R6 shouldn't matter, unless, probably, IGMPv3 snooping was being performed.

However, pinging though R6, likely would matter, for the reason Harold describes.

[Harold Ritter]

@Joseph W. Doherty ,

> did you mean: ". . . does NOT impose . . ."?

That is exactly what I meant. Thanks for pointing it out.

> However, pinging though R6, likely would matter, for the reason Harold describes.

The behavior raised by David, namely IOS being used as a host multicast receiver and not validating the source is a mute point, as packets getting to the receiver with the wrong source address should not happen if the traffic is sourced from anywhere in the network but on the LHR.

[Giuseppe Larosa · Accepted solution]

Hello @Mitrixsen ,

this is case where you should use a true receiver to see what happens. The ping test is not meaningful I'm afraid.

The IGMPv3 join message allows to specify a source you would like to receive traffic from or the opposite to define one or more sources you would not receive traffic from.

Your receiver is actually  a router with an igmp static join and this is an appromixate emulation of a real receiver. The router may answer to the ping even if it is not from the specified source.

Hope to help

Giuseppe

[Joseph W. Doherty]

David, you do ask interesting questions.  ; )

Okay, first of all, it appears you don't have a switch between R6 and your receiver, providing IGMPv3 snooping, supporting SSM, shouldn't be a factor.  I.e. we shouldn't expect IGMPv3 snooping to block the packet.

In your actual ping, you ping 232.0.0.1.  Being a multicast IP, ping will send using a multicast MAC.  Since you didn't specify a source for the ping, I'm guessing the router "knows" that multicast IP lists g0/1 as an egress interface.  Now, ideally, router should also know, there's a specific source IP attached to the SSM multicast IP, but as the ping is likely sourced using the same egress interface, it may not care.  Should it?  Possibly.  Be interesting if you gave ping an explicit source IP different from the egress interface.

BTW, don't know if it matters, but 232.0.0.0/24 is "special" SSM address block.  I suggest you use another address in the /8, such as 232.0.1.1. 

M02@rt37 raised exactly the point I had in mind to discuss, ". . . the host’s network stack may still receive the packet, leaving it up to the application to discard it."

The NIC should recognize the received frame is a multicast MAC, and should check whether that MAC has be noted as wanting to be received.  If not, frame should be ignored, but as multiple multicast IPs map into the same multicast MAC, at this time, we cannot determine if we want the packet or not, so a matching multicast MAC needs to be checked at L3.

At L3, stack likely has a list of IPs that are desired, and if not in that list, packet can be ignored.  But, this multicast IP we do desire.

Forgetting SSM, and using ASM, possibly multiple totally different apps are using the same multicast IP, but the APPs themselves, need to analyze the packets to somehow determine if they want that packet.  Not too efficient, as APPs may need to examine packets they have no interest in.

IP, for other APPs, has the same issue, but to avoid all APPs from looking at all IP packets, IP has a protocol code, like ICMP, UDP, TCP etc.  To further speed of analysis, those protocols often have subcodes/ports.  But what about multicast?  Well, with SSM, we now use the source IP.  It has the advantage of not needing to change the packet's information.

So, very likely, as SSM APPs, won't receive packets without it's desired source IP.

However, the APP that responded was ICMP.  Remember ICMP ping responds to any IP that's accepted by the network stack (ever ping a subnet broadcast IP?), using just that IP.  I.e. it likely doesn't "know" about the distinction between ASM and SSM, and doesn't care.  (Could it, possibly it could, but should it, or shouldn't it, is debatable.  [Including, is it really worth the trouble to do so?])

From a security perspective, we could even debate whether a host should reply to any ASM or SSM (with correct source IP) ping.

In summary, I don't see it as surprising that a host would reply to a ping SSM without the corresponding source IP too.  Again, should it, or shouldn't it?

As to the SSM ping packet being sent to the host, that's even a more complicated question.  As to what would happen, if you tried, as suggested above, an explicit source IP in the ping, or tried the ping from another device on the other side of R6, might have different results.  (In you specific case, I'm unsure how much "multicast routing" was done on R6 for the ping.)

[Joseph W. Doherty · Accepted solution]

So, David, to your questions:

• Do IGMPv3 enabled hosts block packets that have a different source?
• I thought such packets wouldn't be accepted by the host? Is this the normal operation?

No one, so far, I believe, has documented a standard for what "correct" behavior should be.

Without a standard, it appears it's left up to the host, whether to filter out SSM not completely matching the SSM requested by a host APP.  Such unspecified behavior might be somewhat surprising, but often even defined standards can leave questions in their behavior.

For example, you're using ping, but is there a standard that specifies a host is required to respond and/or how fast must it respond and/or must every ping request, from same source, be responded to, etc.?

I wrote earlier about when a situation might be considered too much trouble to worry about vs. the "benefit" of having defined behavior.  How problematic is it, really, not having a defined standard behavior?

There are standards for how SSM should be forwarded, but your case example skips those (much as would the SSM source being on the same subnet as the receiver, w/o IGMP SSM snooping, which, itself, isn't really a standard either  [remember, in original Ethernet, without bridges, all packets types, within the same L2 domain, are received by all hosts]).