Subject: Re: mboned: draft-ietf-mboned-auto-multicast-03.txt

From: Pekka Savola <[email-masked]>
Date: Mon, 8 Nov 2004 14:25:22 +0200 (EET)

On Fri, 22 Oct 2004, Tom Pusateri wrote:
> I just sent a new version of the AMT draft for submission to the IETF.
> The new version has the following changes:
[...]
> Feel free to send feedback right away (you don't have to wait until IETF).

Sorry for waiting ;-).

Some feedback below.

I wonder if you missed (some of) my earlier comments (on list Feb 29)) 
because everything I commented didn't seem to be incorporated.. in any 
case..

substantial
-----------

==> the document does not sufficiently early spell out how it works (or
rather does not work under certain modes) with NATs.  Easy fix would be
s/isolated/isolated non-NAT/ below:

    2. Allowing isolated sites/hosts to transmit the SSM flavor of
       multicast.

...

    Each gateway has an AMT pseudo-interface that serves as a default
    multicast route.  Requests to join a multicast session are sent to
    this interface and encapsulated to a particular relay reachable
    across the unicast-only infrastructure.

==> it's required to have some discussion here about locally-scoped groups,
or global groups which should not be propagated inter-domain (like service
discovery etc.) because the relay will be in a different administrative
domain.  Should the gateway recognize those and not unnecessarily
send those upstream?  Should the relay be configured to ignore them?

5.4.  AMT Membership Query

    An AMT Membership Query packet is sent from the relay back to the
    originator to solicit an AMT Membership Update while confirming the
    source of the original request. It contains a relay Message
    Authentication Code (MAC) that is a non-cryptographic hash of a
    private secret, the originators address, and the request nonce.

==> is there a particular reason to use a MAC instead of just another nonce?
Also know that the security community and the IESG frown strongly upon using
MD5 with new protocols, and I think even if MAC would be used, it would
have to be based on SHA1.

    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.

6.3.  Responding to Relay Changes

    When a gateway determines that its current relay is unreachable
    (e.g., upon receipt of a ICMP Unreachable message [ICMP] for the
    relay's unicast address), it may need to repeat relay address
    discovery.  However, care should be taken not to abandon the current
    relay too quickly due to transient network conditions. Some
    implementations may find it difficult to send a discovery packet to
    the anycast relay address while the gateway has an address configured
    on the AMT pseudo-interface on the same anycast prefix. Therefore, it
    may be necessary to tear down the AMT pseudo-interface to rediscover
    a new relay.

==> why would it be difficult to do that on some implementations?  because
the anycast address is onlink with the interface?  But remember that the
prefix should not be configured on-link, as it's used only for the purposes
of discovering the local unicast address, thus should never be configured
on the interface, right ?

    The IANA should also allocate an Autonomous System ID which can be
    used as a pseudo-AS when advertising routes to the above prefix.
...
    An autonomous system number dedicated to a pseudo-AS for multicast is
    already in use today (AS 10888), and so it is expected that no
    additional AS number is required for this prefix.

==> aren't these in conflict ?

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

    Within the native MBGP infrastructure, there is a risk that a rogue
    router or a rogue AS could introduce a bogus route to the AMT Subnet
    Prefix, and thus divert joins and cause RPF failures of multicast
    traffic.  Again, network managers have to guarantee the integrity of
    the MBGP routing to the AMT subnet prefix in much the same way that
    they guarantee the integrity of all other routes in the M-RIB.

==> this seems insufficient, because it's saying "just do it like you do for
unicast" -- but these prefixes are ANYCAST, also with their own AS number
which anyone can add to their own AS-macro, and even if you did everything
you can using unicast, you could not (completely) protect against
illegitimate hijacking.  This anycast speciality should be discussed in a
paragraph of its own.

    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.

semi-editorial
--------------

    day) to re-resolve the unicast address of a close relay.  The gateway
    also initializes a timer used to send periodic membership reports to

==> s/initalizes/SHOULD initialize/ ?

editorial
---------

==> ToC should be just before the Introduction.  I suggest using tools where
this is trivial to achieve ;-)

The protocol introduced in this
    specification is deployed in a few strategically-placed network nodes
    and in user-installable software modules [...]

==> s/is deployed/can be deployed/ ? :-)

    3. Allowing isolated sites/hosts to receive general multicast (ISM
       [RFC1112]).

==> why not use "ASM" instead of "ISM" ?

    a AMT Relay Discovery message to the AMT Relay Anycast Address, and

==> s/a AMT/an AMT/

13.  Author's Address

==> I count five :)

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