Subject: mboned: draft-ietf-mboned-auto-multicast-06 comments

From: Pekka Savola <[email-masked]>
Date: Sun, 9 Jul 2006 16:07:56 +0300 (EEST)

Hi,

I read the AMT-06 spec, and mostly it's good.  There's at least one 
old issue which is still unresolved, at least one new one, and a 
couple of more minor things.  I think we're getting there... :-)

Section 5.1.3 (this text is new I believe):

    o  Gateway [receiving] report has no tunnel state with a Relay so it
       originates an AMT Relay Discovery message addressed to the Anycast
       Relay IP address.
....
    o  When the Gateway leaves all (S,G) entries, the Relay can free
       resources associated with the tunnel.  It is assumed that when the
       Gateway would want to join an (S,G) again, it would start the
       Discovery/Advertisement tunnel establishment process over again.

==> Note that the AMT Relay Discovery can (and is expected to, as per
different part of the spec) be done prior to gateway receives report.

==> The second bullet seems to imply a misunderstanding.  The whole 
point of AMT is that no state is reserved for idle clients.  Hence, 
gateway must not need to start over with Discovery/Advertisement 
process when it wants to send.  Once it has obtained the unicast 
address of the relay, it can always just send its packets or 
membership reports.

6.2.4.  Relay Address

    The unicast IPv4 or IPv6 address of the AMT relay.  The family can be
    determined by the length of the Advertisement.

==> is this wise?  That way an IPv4 AMT advertisement could include an 
IPv6 address or vise-versa.  That could lead to unexpected 
situations...

6.6.3.  IP Multicast Data

    The original IP Multicast data packet that is being replicated by the
    relay to the gateways including the original IP header.

==> Just to clarify, maybe add something like:

    Encapsulation is part of normal IP processing, e.g., TTL is decremented
    if the packet was forwarded by the relay or gateway.

9.2.2.  IPv6

    As described above in Section 7.2.2 an IPv6 prefix with a length of
    48 is requested.

==> but this was not described in section 7.2.2.  Specifically, the 
prefix length was not described.  This prefix length is insufficient, 
as it will be filtered in DFZ, which will lead to RPF failures.  A /32 
is also needed for this.

==> There might need to be section 9.3 on management of IP address space. 
How should IANA handle reverse DNS (if at all)?  How should IANA populate
any whois records, or help in populating them?

    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:

==> every spec version has had this problem, and I've always commented 
on it, but it has never been fixed.  Maybe we should have an issue 
tracker.. In any case, this is not a proper specification language: 
"If ... then .. MUST".  The result seems to be equivalent to "MAY" 
which is too weak.  I suggest:

    Gateways and relays will accept and decapsulate multicast traffic
    from any source from which regular unicast traffic is accepted.
    The following source address based packet filtering MUST be applied:

==> further, security considerations might need to discuss a couple of more
threats:

  - if IP is spoofed, it could be possible to inject multicast data to 
an SSM transmission originated by an AMT site via AMT Multicast Data 
message. As the message doesn't include any nonces etc., just guessing 
the IP addresses should be sufficient.

  - AFAICS, depending on how the MACs and nonces are chosen (as there 
are no timestamps or such), AMT could be susceptible to replay 
attacks, right? Once you know one packet that gets processed, you 
could repeat that infinitely?  I'm not sure if that's a serious issue 
because you'll need to be on the path to learn the value, but it might 
be something to describe as a remainder issue.

editorial
---------

    The solution we adopt is to assign addresses in anycast
    fashion to relays [RFC1546], [RFC2373].

==> RFC2373 as been obsoleted twice..

    o  Gateway receives report has no tunnel state with a Relay so it
       originates an AMT Relay Discovery message addressed to the Anycast
       Relay IP address.

==> s/receives/receiving/

       Membership Update message.  In the Update message contains (S1,G1)
       in an IGMPv3/MLDv2 formatted packet with an IP header.  The nonce

==> s/In t/T/ or something

       tunnel to the Gateway in it's outgoing interface list for it's

==> s/it's/its/

-- 
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: Dino Farinacci <[email-masked]>
Date: Mon, 10 Jul 2006 04:56:16 -0700

>> different part of the spec) be done prior to gateway receives report.

    Yes, it can but it is not required. So we specified the more optimal
    way to reduce join latency.

>> point of AMT is that no state is reserved for idle clients.  Hence, 

    What is an idle client? A client (or gateway) joined to a (S,G) requires
    state in the Relay.

>> process when it wants to send.  Once it has obtained the unicast 

    When it wants to send? We are talking about the gateway being a receiver
    here. So please clarify what you mean.

>> IPv6 address or vise-versa.  That could lead to unexpected 

    Let's keep this simple and say if the Discovery come over address-family
    x that the advertisement comes over x with a embedded address with 
    address-family x.

    What did you have in mind by doing this?

Dino

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Jul 2006 15:07:16 +0300 (EEST)

On Mon, 10 Jul 2006, Dino Farinacci wrote:
>>> ==> Note that the AMT Relay Discovery can (and is expected to, as 
>>> per different part of the spec) be done prior to gateway receives 
>>> report.
>

I'm not sure if I understand your context.  The join latency is 
reduced if you do AMT relay discovery before you actually need to join 
the group, right?  Otherwise you'll have do 2 3-way handshakes before 
the join gets active instead of just one.

>    What is an idle client? A client (or gateway) joined to a (S,G) requires

An idle client is one that doesn't receive or send.  I think we're in 
agreement here.  See below.

>    here. So please clarify what you mean.

The text says:

    o  When the Gateway leaves all (S,G) entries, the Relay can free
       resources associated with the tunnel.It is assumed that when the
       Gateway would want to join an (S,G) again, it would start the
       Discovery/Advertisement tunnel establishment process over again.

I'm OK with the first sentence in principle, but it seems to hide the 
issue hinted by the second sentence.  The second sentence is dead 
wrong on so many levels.  It also seems to be saying that by your 
understanding, relay discovery sets up a tunnel to the AMT site, and 
when the sending or receiving stops, that tunnel is removed (i.e., 
state is created during AMT relay discovery which is against the "idle 
client" principles).

>    x that the advertisement comes over x with a embedded address  with

Yes, that would be simpler.

>    What did you have in mind by doing this?

I'm not sure what you mean with "by doing this"..

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 10 Jul 2006 05:26:18 -0700

>> agreement here.  See below.

    Yes, synced now.

>> issue hinted by the second sentence.  The second sentence is dead 

    I see the disconnect between the two sentences. But that means if
    the Relay removes all state it will not know the discovery nonce. But
    I guess that is okay.

>> state is created during AMT relay discovery which is against the "idle 

    Okay, I agree with you and see what you mean now. How about we change
    the text to:

    o  When the Gateway leaves all (S,G) entries, the Relay can free
       resources associated with the tunnel. When the Gateway would want to 
       join an (S,G) again, it could optionally start the Discovery/
       Advertisement tunnel establishment to find a new Relay.

    Then we just don't get Relay spread at one-day granularity but can for
    when a Gateway goes from not being joined to anything to being joined
    to something. A bit more reactive but not necessarily too dynamic.

>> I'm not sure what you mean with "by doing this"..

    No worries, we are in agreement and synced.

Dino

---

From: Pekka Savola <[email-masked]>
Date: Mon, 10 Jul 2006 15:29:57 +0300 (EEST)

>    to something. A bit more reactive but not necessarily too dynamic.

This looks fine to me.

Thanks!