Subject: Re: [MBONED] AMT Sourcing concerns

From: Tom Pusateri <[email-masked]>
Date: Sun, 7 Mar 2010 20:04:24 -0500

On Feb 11, 2010, at 6:08 AM, Pekka Savola wrote:

> On Wed, 10 Feb 2010, Greg Shepherd wrote:
>> I'm very concerned that the current sourcing specification in the AMT draft is at best
>> unscaleable, though I honestly feel it is simply unworkable. The idea of requiring a sourcing
>> Gateway to respond to and establish multiple tunnels in order to source goes against the very
>> design goals set out for AMT at the Vienna MLM BOF. In addition, requiring the Gateways to
>> respond and establish multiple tunnels on behalf of receivers potentially opens up security
>> concerns which are not even addressed in the draft.
> 
> Please note that AMT precedes MLM BOF, and as is described in the draft, if the amount of traffic to be sent by the gateway would be excessive, the gateway should join the native infrastructure by some means (e.g. a tunnel).  AMT is not a one-size-fits-all solution for all multicast tunneling needs IMHO.
> 
>> First, my security concern is that this could happen to any host whether or not it is
>> actually sourcing any traffic. But since this is Relay-generated the sourcing Gateway may
>> (will) end up with multiple AMT tunnels to relays - my primary concern.
> 
> It's not clear to me what exactly the security concern is.  Are you referring to the case where someone would forge an (S,G) join for S that does not even implement AMT, and in consequence that would result in relays encapsulating a couple of UDP packets to that S address?  If so, it's true that this could be discussed in Security Considerations; it's mentioned in Section 5.1.2 though.
> 
>> What I propose in order to maintain a SINGLE AMT tunnel to/from any Relay/Gateway pair and
>> still support sourcing is to remove any address generation mechanism from the spec, and
>> remove Relay-driven joins to (potentially) sourcing Gateways.
> 
> I personally object to the notion of address assignment from a relay for multiple reasons:
> - AMT gateway source-flooding ("a ramen/MSDP worm") would create state and reserve addresses even though there are no recipients for the traffic.  Currently no state is kept at relay until someone wants to receive.
> - adding such a mechanism would complicate the spec, and we're really reinventing DHCP-like mechanisms and I suppose would be non-trivial
> - I don't really want to require relays to keep this kind of pool (note that if all don't do it, the user's experience might vary depending on the closest relay)
> - as a potential relay operator, I don't cherish the idea of giving access to my IP addresses for sourcing any kind of content they want. The current model where the relay operator is not visible is more "transparent".
> 
> If sourcing AMT as it is felt to be a problem, I'd prefer removing AMT sourcing from the spec, to be left for future specification(s). (I'm not sure if this is a critical feature of the spec as there are already a lot of requirements such as public IP, co-locating the sender at Gateway, etc.)
> 

I'm updating the spec tonight trying to make the dealine in the morning. I saw Greg's request here and Pekka's response but not anything from Greg acknowleging it. Greg, are you ok with the current sourcing scheme or do you still require changes?

Thanks,
Tom

---

From: Greg Shepherd <[email-masked]>
Date: Sun, 7 Mar 2010 18:30:40 -0800

Tom,

I did respond. And, no, I'm not at all happy with the current source
address allocation mechanism.

What I proposed was to remove the source address allocation all
together. The draft mentions tunnel-brokers as a potential solution,
so why not let the tunnel-brokers use AMT and them choose how they
want to allocate source addresses. The spec may then need another
message to request an address. Does this make sense?

Greg

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 7 Mar 2010 23:53:35 -0500

Thanks Greg. I just missed it but I did go back and see your comments. I'm a little confused so I didn't include any of this in the lastest draft but we can work on it and I'll submit another one. Let me re-read your comments and Pekka's and make sure I understand the concern.

Thanks,
Tom