Subject: mboned: re-review: draft-ietf-mboned-auto-multicast-05

From: Pekka Savola <[email-masked]>
Date: Mon, 7 Nov 2005 18:34:19 +0200 (EET)

Hi,

I checked the new version against -04 and the commments I made.  I 
believe the following issues are still open, and I believe most of 
them should be addressed; especially the first one is a show-stopper.

[...]
    Finally, to support sourcing traffic to SSM groups by a gateway with
    a global unicast address, the AMT Subnet Prefix is treated as the
    subnet prefix of the AMT pseudo-interface, and an anycast address is
    added on the interface.  This anycast address is formed by
    concatenating the AMT Subnet Prefix followed by the high bits of the
    gateway's global unicast address.  For example, if IANA assigns the
    IPv4 prefix x.y/16 as the AMT Subnet Prefix, and the gateway has
    global unicast address a.b.c.d, then the AMT Gateway's Anycast
    Address will be x.y.a.b.  Note that multiple gateways might end up
    with the same anycast address assigned to their pseudo-interfaces.

==> here and in many places as well you discuss how v4 prefix tricks
are to be used, but you should also be discussing how the
manipulations/assignments would be done for v6.

[[200511: note: IANA allocation request has been added but the prefix 
tricks are not described.  Further, the IANA allocation size for v6 
needs to be /32 not /64]]

.......

==> there is an important issue which needs to be discussed.  Who will
maintain the prefix/AS records in RADB/RIPE/.. etc. whois databases?

[[200511: while it's clear that DaveM or someone will maintain these 
objects, I fear that unless weinstruct the IANA to give this control, 
it won't happen (at least befor eVERY lengthy debates.  Thus I think 
the doc should say something about this.]]

    Gateways and relays will accept and decapsulate multicast traffic
    from any source from which regular unicast traffic is accepted. If
    this is for any reason felt to be a security risk, then additional
    source address based packet filtering MUST be applied:

==> this is totally bogus way to specify this, it's saying like "if the
implementor thinks it makes sense, do X", effectively creating a loophole
where you can be compliant with the spec but not do the checks.  Just say
that implementations MUST do these.

==================================

> > > >    2. The AMT Subnet Prefix is advertised for RPF reachability in
> > > > the
> > > >    M-RIB by relays and gateways.
> > > > 
> > > >    3. Relays or gateways that receive a join for a source/group pair
> > > >    use information encoded in the address pair to rebuild the
> > > > address
> > > > 
> > > > ==> only relays need to do these, AFAICS. (should be clearer)
> > > 
> > > Its worded this way because a gateway that is sourcing multicast data
> > > could
> > > receive a join from a gateway.
> > 
> > OK -- but how could you expect the gateways to advertise the AMT
> > subnet prefix?
> 
> They don't have to. They send to relays or other gateways only.

Isn't this and your earlier comment contradictory, or am I missing
something?  First you said that the text above is needed (in particular, the
point 2 above about advertising the subnet prefix), but then you said it
doesn't need to be advertised by the gateways??

I think this could be clarified by the use of active instead of passive
voice, so the text would answer questions like "who needs to advertise?  to
whom?  how?"

> > > > ==> there are at least [one] issue which need description:
> > > >  1) SSM (S,G) joins from native multicast to AMT gateway -- describe
> > > > how
> > > > these are secured.
> > > 
> > > The join mechanism is already described.
> > 
> > Sorry, I can't see where -- AFAICS, the security considerations only
> > lists how you secure the *encapsulation/decapsulation* (e.g.,
> > relay-gateway, gateway-gateway), but not native host - relay (and from
> > there to the gateway) ?
> 
> Can you explain the threat you are concerned about?

I do not think there is any specific threat, but it is a gap in the current
threat analysis.  For example, at the end you could say:

The above two checks ensure that the addresses in the AMT packets match the
IP source source address, enabling easier tracing of abuse. It is still
possible to perform DoS attacks on routers or relays. This document
specifies no mechanisms to prevent attacks from native multicast sources or
receivers, though multicast RPF mechanisms should make abuse easy to trace.
The implementers may want to experiment with different kind of rate-limiting
strategies to evaluate these potential threats.

(The last sentence could be left out as well, but for an experimental spec I
don't think it hurts)

> > > Yes. How about:
> > > 
> > > The gateway MUST also be advertised in the M-RIB (or the normal
> > > unicast routing table if unicast and multicast topologies are
> > > congruent) to ensure received multicast packets are not discarded
> > > because they are received on the wrong incoming interface.
> > 
> > I don't think this clarifies it sufficiently yet.  The point is that
> > all you need to ensure is that the site's AMT gateway is RPF-wise OK
> > *inside the site* -- and the site doesn't have to advertise anything
> > at all outside the site, right?
> 
> Ok. I changed this to:
> 
> Hosts receiving multicast packets through a gateway should ensure
> that their M-RIB accepts multicast packets from the gateway for the
> sources it is joining.

This is better, but sounds a bit like something that was written by a PIM
person ;-)

Let me try if I can understand the issue you want to address well enough to
try to change that into a form that may be easier to understand.  (I'm still
not sure, but bear with me.) Maybe:

  The site's internal topology must be RPF-wise correct in M-RIB, so
  that the gateway can accept joins or data packets from the receivers
  and sources inside the site.

The above only happens if the site has multiple routers, running e.g., PIM,
and the gateway just "redistributes" these to IGMPv3/MLDv2 using AMT.  The
above should be trivially accomoplished when the gateway is a host or a
single router (AFAICS)

As far as I understood,
  1) the relays don't need to do anything out of ordinary (I don't think the
gateways' unicast addresses need to be in M-RIB, because you don't get any
PIM packets from there, and this spec doesn't do any RPF-like filtering) and

  2) the only thing gateways have to ensure toward relays is that their M-RIB
entry for the relay(s) [and other gateways] points to the AMT interface (or
something like that), and not the internal network. This should be trivial
unless the site has configured a multicast null0 default route or
something...

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/