Subject: [MBONED] AMT Sourcing concerns

From: Greg Shepherd <[email-masked]>
Date: Wed, 10 Feb 2010 09:25:59 -0800

First of all, sorry for waiting so long to step in here..

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.

Okay, that said, let me try to suggest a solution.

First of all, in order for a Gateway to source traffic, it must use a source
address of the pseudo interface which is globally unique and reachable to
ensure the RPF mechanism of PIM builds the tree to the correct device. The
draft currently specifies how to generate this source address, but in a way
that then requires any Relay receiving a join for that source to decode and
initiate a join to that decoded Gatway address:

*5.2

3.  Relays or gateways that receive a join for a source/group pair use
information encoded in the address pair to rebuild the address of the
gateway (source) to which to encapsulate the join        (see Section 7.2
for more details).  The membership reports use the same three way handshake
as outlined in Section 5.1.2

If a relay receives an explicit join from the native infrastructure,    for
a given (source, group) pair where the source address belongs to    the AMT
Subnet Anycast Prefix, then the relay will periodically    (using the rules
specified in Section 5.1.2) encapsulate membership    updates for the group
to the gateway.  The gateway must keep state    per relay from which
membership reports have been sent, and forward    multicast traffic from the
site to all relays from which membership    reports have been received.  The
choice of whether this state and    replication is done at the link-layer
(i.e., by the tunnel interface)    or at the network-layer is implementation
dependent.
*
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.

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.

Alternatively, and Gateway wishing to source would send a Relay discovery
message to setup the AMT tunnel - one tunnel. The pseudo interface on the
sourcing Gateway will need to use a source address FROM WITHIN the AS of the
connected Relay. This will ensure that native mcast will RPF correctly all
the way back to the connecting Relay then down through the tunnel to the
sourcing Gateway.

This will require the Relay implementation to select an address by any means
acceptable to the operational standards of the Relay's hosting network -
outside of the AMT specification. But it will also require the Relay to
assign this address to the sourcing Gateway upon request. This may require
one additional message handshake:

GW -> Relay: ReqSrcAddr
Relay -> GW: SrcAddr

The Relay->Gw join message should remain so that any sourcing GW will NOT
send packets up the tunnel until the upstream Relay has OIF state for the
(S,G) pair.

Am I making sense?

Thanks,
Greg

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Feb 2010 13:08:13 +0200 (EET)

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.)

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

---

From: Greg Shepherd <[email-masked]>
Date: Thu, 11 Feb 2010 06:32:47 -0800

On Thu, Feb 11, 2010 at 3:08 AM, Pekka Savola <[email-masked]> wrote:

> Please note that AMT precedes MLM BOF,

Plese note that AMT had expired before the MLM BOF and that it was the
decision of the BOF that the AMT draft was a close enough fit to use as a
foundation to implement the rest of the reqs of the BOF rather than start a
new draft from scratch.

> 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.
>

Because it is described in the draft doesn't make it write. And asking the
Gateway to "join the native infrastructure by some means" sounds a bit
absurd. The entire purpose of AMT is to allow mcast connectivity into non
mcast connected sights.

> 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.
>

I was most concerned with the state, but the handshake will prevent this.
Okay, we can disregard the security concerns as they were secondary anyway.
I'm most concerned with creating a workable specification addressing the
primary need of providing mcast connectivity.

>> Relay/Gateway pair and
> 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.
>

There is not state until requested.

> reinventing DHCP-like mechanisms and I suppose would be non-trivial

What I proposed was to NOT create nor specify any such mechanism, but to
leave it out of scope.

>  - 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)
>

And I do for many reasons. Sourcing support should be a MAY anyway. But it
should be a workable solution.

>  - 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".
>

Then don't support it.

> 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'd rather it not be in the spec rather than live as it is. But what I
proposed was a mechanism to enable sourcing but to remove the addressing
mechanism from the AMT draft so that the draft will at least be a first
step.

Greg