Subject: Re: mboned: WGLC for draft-ietf-mboned-auto-multicast-04.txt

From: Tom Pusateri <[email-masked]>
Date: Wed, 11 May 2005 09:39:20 -0700

Pekka,
	Sorry for taking so long to respond to this.

In message <[email-masked]> you write:
>On Fri, 8 Apr 2005, David Meyer wrote:
>> 	 ftp://ftp.ietf.org/internet-drafts/draft-ietf-mboned-auto-multicast-04
>.txt
>>
>> 	Please review the document carefully, and send your
>> 	feedback to the list.  Please also indicate whether or
>> 	not you believe that this document is ready to go to the
>> 	IESG.
>>
>> 	This Last Call will end on 22 Apr 2005 at 1400 PDT (UTC/GMT-7).
>
>I believe this is very important work (which also means it the 
>time-to-market is important, so we should be finished with this soon) 
>in making multicast available to everyone, but I think this still 
>needs about 1-2 revisions (below).
>
>Dave M., what is the intended category?  Experimental or Proposed 
>Standard?  This requires extensive work for PS, but I could be 
>convinced that if we go for Experimental first the document might not 
>need to be as good at this point.  The most important thing, in the 
>end, is creating a sufficiently stable spec and making the IANA prefix 
>assignments so this can be deployed.

Experimental

>My comments to -03 (sent on the list on November 2004) have not been 
>responded or integrated; I guess they were lost.  They are below.

I thought I did but I guess not.

>Also, many comments to -02 weren't discussed or adopted either; I've 
>included these at the end as well (removing the obsolete ones).

Ditto.

>new issues
>----------
>
>1) MAC calculation also includes the source port in the calculation. 
>However, note that the relays must not do so for the packets received 
>from gateways because if there is NAT in the path, the source address 
>and port will be changed and MAC does not verify.  Maybe the spec 
>should be clearer which how to create and verify the MAC (from 
>different nodes' perspectives)?

The MAC calculation is only calculated and verified on one end so
the relay will only ever see the same source port in the received
header so its calculation will always match. Therefore, its fine
to leave this in.

The gateway sees this as an opaque value and neither verifies it
or knows how it was generated.

>2) the document should be clearer about how this interoperates with 
>NATs, i.e., in which cases the gateway can be behind a NAT.  If the 
>traffic between gateways is sent directly (this is a MAY), the sender 
>cannot be behind a NAT, at least, because otherwise NAT translation 
>state does not exist and the IGMP join is discarded by the NAT.  So, 
>as NAT traversal requires much more than just using UDP and tuning 
>IGMP/MLD intervals, for example the following requires clarification:
>
>    All multicast packets (data and control) are encapsulated in unicast
>    packets.  To work across NAT's, the encapsulation is done over UDP
>    using a well-known port number [TBD IANA].

I'm not sure I follow. The outer UDP header gets natted (is that a verb)
but the inner IGMP packet remains unchanged. The group and possible source
address (IGMPv3 include) is extracted from the inner IGMP packet and the
packets get encapsulated to the gateway address and port in the outer header.
There really isn't alot of extra magic needed to make NAT traversal work.

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

The gateway can be seen as a host extension of the relay's network.
In some cases you might want scoped addresses to reach the gateway.
In other cases you may not. I think the implementations should be flexible
enough to allow for either case.

It might be worth pointing out in the spec that this issue exists though.

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

Agreed. This will be addressed in the next version.

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

Maybe this should be taken back out because it is a very operating system
specific issue. We are trying to create an environment that is transparent
to the application on the host gateway so if we want the application to
source multicast packets with using an address out of the AMT prefix range,
that address will most likely be configured on the interface.

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

Dave Meyer felt we should not re-use 10888 anyway (especially since its
owned by NASA Ames) so we will remove this.

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

Dave Meyer. ;-)

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

Ok, we're willing to accept any text contributions.

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

Ok, we can reword this.

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

got it.

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

Since the ToC is optional, we should be happy to have one at all! ;-)

>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/ ? :-)

fixed.

>
>    3. Allowing isolated sites/hosts to receive general multicast (ISM
>       [RFC1112]).
>
>==> why not use "ASM" instead of "ISM" ?

fixed.

>    a AMT Relay Discovery message to the AMT Relay Anycast Address, and
>
>==> s/a AMT/an AMT/

fixed.

>
>=======================================================
>comments to -02 which apparently haven't been addressed
>=======================================================
>
>substantial
>-----------
>
>    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.

>    The solution above will scale to an arbitrary number of relays, as
>    long at the number of relays requiring multicast traffic from a
>    given AMT site remains reasonable enough to not overly burden the
>    site's gateway.
>
>==> umm, e.g. with 10 or 15 recipients, with reasonably large packets,
>slower links (such as those used by typical AMT deployers) would already be
>highly congested -- and what's worse, all the transmissions would always be
>simultaneous.
>
>Luckily enough this is not a *huge* problem, as the sites are only likely
>recipients, not senders.  But the problem is just changed the other way
>around, to the relays, which might need to encapsulate, simultaneously, to
>even 100 or 1000 sites.  This could be pretty high as well, especially if
>the encapsulation is done in the slow router CPU..

I guess I didn't respond to this because I saw it more of a statement
than a question. Since this is an experimental protocol, we will
hopefully discover where the bottlenecks are during deployment and
be able to revise the protocol as improvements are made. With all of
the switch redundancy features out there, there may be another solution
here that we discover during deployment.

>
>    Finally, to support sourcing traffic to SSM groups by a gateway with
>    a global unicast address, the AMT Subnet Prefix is treated as the
>
>==> this wording, the same later in section 6.3, seems to be ignoring the
>possibility that gateway is not necessarily the host sending/receiving.
>
>==> further, it might be important to say a few words on the multicast
>address assignment procedures which you're relying on here.  As it is, the
>apps and hosts must know somehow that they use the correct group addresses...

Sourcing is only supported for SSM groups in which case the group address
policy is determined on the source and is outside the scope of this
document.

>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 for the relay's
>    unicast address), it immediately repeats the unicast address
>    resolution step by sending a UDP encapsulated ICMP Echo Request to
>    the AMT Relay Anycast Address, and storing the source address of the
>    UDP encapsulated ICMP Echo Response as the new unicast address to
>    use as a "link-layer" destination.
>
>==> s/a ICMP/an ICMP/
>==> there seem to be some remnants of ICMP here, which should be AMT Relay
>Discovery process, I guess.
>==> If there are existing joins (or transmissions) when the relay is
>changed, should there be some text to suggest that the join should be
>resent, or the transmission stopped until a new join is received (or the
>like)

No, this is the case where a gateway was sending to a relay AMT port
and the relay wasn't listening on the AMT port (the relay process died
or was disabled or the box is rebooting). The gateway will get an ICMP
port unreachable message back. At this time, the gateway may want to
try and locate a new relay.

>6.7. Sending data to SSM groups
>
>[...]
>
>    If the group address is an SSM group, then the packet is unicast
>    encapsulated to each remote node from which the gateway has received
>    an IGMPv3 report for the packet's (source, group) pair.
>
>==> this seems to create an implicit requirement for "MSNIP--"
>functionality: the AMT code must know whether there have been any joins to
>the group, before sending out anything.  Regular multicast implementation woul
>d
>just toss all the packets to the relay...

The rest of the document describes how the join mechanism can work in
either direction.

>9. Security Considerations
>
>==> 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.

>
>editorial
>---------
>
>    to exchange multicast traffic with the native multicast
>    infrastructure (MBone) and does not require any manual
>
>==> please eradicate any references to "MBone".  Such thing doesn't really
>exist anymore :-)

Fixed.

>This discovery should be done periodically (e.g., once a
>    day) to re-resolve the unicast address of a close relay.
>
>==> should this last "should" be upper-cased?

Fixed.

>
>  The gateway MUST also advertise itself as the default
>    route for multicast in the M-RIB (or it must be the default unicast
>    router if unicast and multicast topologies are congruent).
>
>==> would it make sense to clarify that this advertisement is only needed in
>the site's internal topology?

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.

>   If S is not the AMT Gateway Anycast Address of the gateway, the
>    packet is dropped.
>
>==> s/dropped/silently discarded/ (everywhere) ?

Fixed.

>[References]
>==> as MBGP is mentioned so many times, a suitable reference should be added
>here, I think.

Fixed.

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

---

From: Pekka Savola <[email-masked]>
Date: Tue, 17 May 2005 12:57:08 +0300 (EEST)

Comments inline (I removed the very clear cases from the mail)

> or knows how it was generated.

OK, I didn't catch that.   I think the document should be clearer that 
the inputs for the MAC (in addition to the algorithm) can be chosen at 
will; maybe reword to:

    When a gateway or relay wants to send a membership report, it first
    sends an AMT Request with a request nonce in it. The receiving side
    (the respondent) can calculate a message authentication code (MAC)
    based on (for example) the source IP address of the Request, the
    source UDP port, the request nonce, and a secret key known only to
    the respondent. The algorithm and the input used to calculate the
    MAC does not have to be standardized since the respondent generates
    and verifies the MAC and the originator simply echoes it.

> There really isn't alot of extra magic needed to make NAT traversal work.

To be able to send packets from non-natted host A to natted host B, 
B will first have to initiate the NAT state by sending a packet to A 
(and maintaining that state regularly).  The spec is OK as long as 
"Host A" in this case is the AMT relay, but when it's a host, it's not 
clear how host A could get host B to open the "NAT pinhole".

But do you support sending packets directly between a natted host C 
and natted host B?  If B sends an initiating packet to C, it will be 
discarded at C's NAT because it lacks state; if C sends an initiating 
packet to B, it'll be discarded equally.  Hence a problem.  Solving 
this requires pretty complicated procedures (see e.g., 
draft-huitema-v6ops-teredo-05.txt), but this could possibly be ruled 
out of scope of this spec.

The spec would roughly OK if the AMT tunnels could not get built 
directly between the AMT sites, but because they can, the implications 
with getting the NAT mapping state established haven't been 
considered.

> It might be worth pointing out in the spec that this issue exists though.

For Experimental specification, I think pointing out the issues is 
probably sufficient at this point.

> that address will most likely be configured on the interface.

Yep, though this will be very easily solved by pointhing a (more 
specific) host route to the AMT relay, right?

So, at least for me, the above clarification confuses more than it 
helps.  Maybe remove the following:

     Some

and replace it with a less explicit "watch out" note:

     The implementation SHOULD allow sourcing multicast on
     the gateway while rediscovering a new relay.

(or something else like that..)

> owned by NASA Ames) so we will remove this.

OK.

>> maintain the prefix/AS records in RADB/RIPE/.. etc. whois databases?

Put that in the spec in some generic form. :)

> Ok, we're willing to accept any text contributions.

For example, replace:

with something like:

     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.  As the AMT Subnet Prefix is distributed with anycast,
     guaranteeing the integrity of the MBGP advertisement is much more
     challenging than verifying the correctness of a unicast
     advertisement.  To mitigate this threat, the routing operators
     should configure the BGP sessions to filter out any more specific
     advertisements for the AMT Subnet Prefix.

It might also make sense to add an informative reference to 
raft-ietf-grow-anycast-00.txt, but at least at the moment that 
document doesn't discuss this (more generic) anycast advertisement 
security problem at more length.

There could also be some discussion of limiting who can advertise the 
prefix (based on RIPE/ARIN/RADB etc. prefix/ASN lists), but the 
current design (the use of a pseudo-AS) doesn't seem to support it 
very well.

> Since the ToC is optional, we should be happy to have one at all! ;-)

No, ToC is _required_ for all drafts longer than 15 pages, see 
http://www.ietf.org/ID-Checklist.html

> receive a join from a gateway.

OK -- but how could you expect the gateways to advertise the AMT 
subnet prefix?

> here that we discover during deployment.

OK enough for experimental.

> policy is determined on the source and is outside the scope of this

I may be missing something, but I thought a bit of magic was encoded 
in the SSM address (see the security considerations example of 
232.c.d.e, where c and d are special); if so, this issue shoul 
definitely be called out very clearly (practically requiring manual 
config), but there wouldn't need to be automated solutions for 
Experimental.

Also the cases where the SSM channel is sourced by the gateway or a 
host behind the gateway should be (close to) equivalent ?

> try and locate a new relay.

The current text is good enough for Experimental, though it might be 
good to say a few words on what happens with packets being sent while 
the ICMP was received and the new relay is being discovered (discard 
packets, send to the old relay, unspecified, ...).

>> the group, before sending out anything.  Regular multicast implementation would

Not sure if my comment is clear enough.  I was commenting on the 
generic issue that this spec requires storing state of transmissions 
and interest of the site.  This is not far from what IGMP proxying is 
doing, but it might not hurt to say it explicitly.

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

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

If the gateways need to do any M-RIB advertisements outside of the 
site, these will need to be very clearly spelled out.

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 23 May 2005 11:59:51 -0700

>    and verifies the MAC and the originator simply echoes it.

Yes, this is good.

>out of scope of this spec.

Yes, NAT sites cannot be sources. I've clarified the problem statement
in the introduction.

>probably sufficient at this point.

Ok. I added:

Implementors should be aware that site administrators may have
configured administratively scoped multicast boundaries and a remote
gateway may provide a means to circumvent administrative boundaries.
Therefore, implementations should allow for the configuration of
such boundaries on relays and gateways and perform filtering as needed.

>(or something else like that..)

I just removed it entirely since it is so implemention dependent.

>Put that in the spec in some generic form. :)

ok.

>     advertisements for the AMT Subnet Prefix.

Ok, I get your point.  The prefix isn't distributed with anycast.
It is simply a prefix that may be advertised by more than one entity.
So I took your text but tweaked it slightly.

>draft-ietf-grow-anycast-00.txt, but at least at the moment that 

I think that's a good idea. I'll have to better understand how these
databases affect what prefixes are accepted. This will be something
we can experiment with as we deploy more sites.

>http://www.ietf.org/ID-Checklist.html

Ok. Its a bit late to convert this to XML but I'll dig up Bill Fenner's
macros for putting the ToC at the beginning.

>OK -- but how could you expect the gateways to advertise the AMT 

They don't have to. They send to relays or other gateways only.

>config), but there wouldn't need to be automated solutions for 

Ok. I have a diagram to add that will clarify this.

>host behind the gateway should be (close to) equivalent ?

Yes.

>relay-gateway, gateway-gateway), but not native host - relay (and from 

Can you explain the threat you are concerned about?

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 25 May 2005 12:45:22 +0300 (EEST)

Inline, responding to just two open points,

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

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

...

You may or may not want to add informative reference to RFC3964 which 
analyses the stuff for 6to4 at great length; due to the handshake, the 
issues are a bit different, but DoS attacks still have a degree of 
similarity.

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

> that their M-RIB accepts multicast packets from the gateway for the

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