Subject: [MBONED] AMT discussion summary

From: Tom Pusateri <[email-masked]>
Date: Wed, 10 Mar 2010 22:13:38 -0500

I will take the time to summarize all this because there is so many bits and pieces and I'm working on several different things right now and probably wasn't being coherent (besides the fact that I responded to Dino with assumptions that weren't true).
----------------------

In order for a relay to make sure they can receive the multicast groups they ask for, we have a 3-way handshake. Ask for a query, receive a query with a response MAC, send back the response MAC and add/drop group membership.

When you change IP addresses, you can send from the old address and port but you can no longer receive packets to the source address/port. This means the 3-way handshake is broken and if the relay still accepts group add/drop membership reports from a source it can't reach, then anyone can send them, not just the gateway that can receive them.

The 3-way handshake also creates forwarding state in the NAT box between the gateway and relay. This allows the multicast data to come in through the NAT since the packets requests originated inside the NAT. Of course, the relay doesn't have to receive the same source address as the gateway sends but it does have to receive a consistent source address and port from which it calculates the response MAC.

Without your scenario of an address changing on the gateway, if packets are routed from the gateway to a relay through a parallel path and a different NAT box, the source address/port could change and break the 3-way handshake. If the gateway loses its source address, due to an interface going down and switching to another provider or just a DHCP address change, the chances of going upstream through a different NAT box increase. If the gateway continues to send with the old source address/port, then in some cases, the source address/port that shows up at the relay may still be the same and in other cases it may change because its going through a different NAT box.

So, if we add the teardown message and you re-use the response MAC, you can in some cases achieve what you want, and in other cases, you're no better off. If you've passed the lifetime of the response MAC, you can't use the old source address/port because you need a new 3-way handshake.

But the first objection to the Teardown message was that it strayed from the IGMP model of add/drop membership. This muddies the protocol and if it worked all the time, then it would be easier to justify but when it only works some of the time, the justification for breaking the IGMP model is weakened.

The second objection is that anyone along the path can see all the info they need to generate a Teardown message for a DOS attack. To be clear, this could happen anyway with AMT Membership Update messages and therefore, it is recommended to keep the lifetime of the response MAC as short as possible to reduce the window for DOS attacks. Some may decide that a response MAC is only good for a single AMT Membership Update message and cannot be reused. This would require a 3-way handshake each time and so you could not re-use the source address/port if you can't receive packets for that address.

If we opt to encode the addresses/port numbers in the packet, then we must interact with the NAT box to know what the source address/port is and be updated when it changes as a result of a new local address or port. This can be done with things like STUN, TURN, ICE, NAT-PMP, etc. This will complicate things a bit but there are other protocols doing this so we wouldn't be forging new ground.

One way to fix the 3-way handshake problem when source addresses/ports change is to change the response MAC to not be dependent on addresses or port numbers and to encrypt it to prevent it being injected by someone on the path. This would actually be a stronger security measure than what we have today at the expense of crypto methods like public/private key pairs.

Thanks,
Tom

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Mar 2010 12:39:36 +0200 (EET)

On Wed, 10 Mar 2010, Tom Pusateri wrote:
> Without your scenario of an address changing on the gateway, if 
> packets are routed from the gateway to a relay through a parallel 
> path and a different NAT box, the source address/port could change 
> and break the 3-way handshake. If the gateway loses its source 
> address, due to an interface going down and switching to another 
> provider or just a DHCP address change, the chances of going 
> upstream through a different NAT box increase. If the gateway 
> continues to send with the old source address/port, then in some 
> cases, the source address/port that shows up at the relay may still 
> be the same and in other cases it may change because its going 
> through a different NAT box.

I'm not sure if I understand what the problem is, i.e. why a change is 
needed to spec at all.

Is the concern that when the gateway changes its IP or NAT mapping 
gets reset, multicast data will keep on being encapsulated to the 
wrong IP (and/or dropped in the NAT box), wasting resources or ending 
up in dev/null?

If so I don't see why this is a major problem given the transmission 
will expire on its own later; the same AFAIK also exists in UDP-based 
streaming services.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings