Automatic Multicast Tunneling
draft-ietf-mboned-auto-multicast-18

I have no objeciton ot the publication of this document as an RFC, but some
comments from the Routing Directorate review by Dimitri Papadimitriou are
included below. I agree with these comments and have updated the text
with my own queries.

You may be able to address these comments with email or small changes to
the text.

---

Section 4.1 states 
   A gateway or relay implementation does
   not necessarily require a fully-functional, conforming implementation
   of IGMP or MLD to adhere to this specification, but the protocol
   description that appears in this document assumes that this is the
   case.

I am not sure what this statement intends to actually say. Similar 
statement is made in Section 5.2.1

---

Section 4.1.3.1.

Figure seem to imply only PIM-SM can be used? Is this the intention?
if so, it might be a good idea to call it out in the text. If not, maybe
make clear that the figure is only an example.

---

Section 4.1.4.1

Any specific reason to impose a "provider-specific relay discovery 
mechanism" or "a private anycast address" to obtain access to these
relays. What prevents making them "publically accessible"?

---

Section 4.1.5.1

The concept of "unicast Relay" and "unicast Relay address" appears for
the first time but isn't yet defined.

---

Section 4.2.1.1

Means by which the "Relay Discovery Address" is being advertised should
be documented or referenced.

---

Section 4.2.1.1 point 2

How can the GTW verify that the responder (or the entity responding on
behalf of it) is the actually the RELAY it pretends to be?

---

Section 4.2.1.1

This section doesn't provide any details concerning timing, error
situations (what happens when a message is lost?), and means to overcome
such situations. Further down the text (Section 5.2.X/5.3.X) these
details are provided so maybe just add a forward pointer.

---

Section 4.2.1.2

What is the default setting for the timer mentioned in "Each time the
gateway receives a Membership Query message it starts a timer..."

---

Section 4.2.1.2 point 3

Expand the acronym QQIC

---

Section 4.2.1.2 point 10

Usually one refers to a stream of mcast messages, so does the relay
encaspulate messages 1 by 1? What happens if the incoming message is too
long to be transmitted towards the gateway?

---                                                                   

Section 4.2.1.2

Where you say "or the relay receives a valid Teardown message from the
gateway" please at a pointer to the next section.

---

Section 4.2.1.3

The text seems to imply that the message SHALL only be used in the 
conditions described in that Section, but prevents other usage e.g. 
sending a Teardown without prior Membership Query/Update message.

Is this really the intent?
                                                                 
---

Section 4.2.1.4

The philosophy seems to be that a GTW may receive incoming mcast traffic
from the Relay after a long waiting period, but in this case all
listeners might have "left". How comfortable are you that this type of 
asynchronous mode will be effective?

---

Section 5.1.3

It looks really odd to put the P flag in the middle of the two reserved
fields. I can see you intend one byte of flags (with seven flags 
reserved) and two bytes of pure reserved field.

If this was your intent, I think you should label the first reserved 
field as "Flags" and set up an IANA registry (including allocation
policy) for the rest of the flags.

OTOH if you want the reserved fields to be completely available for any
future use, then perhaps you should put the P flag in bit 8. 

---

Section 5.3.3.6

Should you be concerned about traffic ordering issues in the exchange
between Relay downward to the GTW as there is intermediate processing
on both entities?

---

Section 6

You say 
   AMT is not intended to be a strongly secured protocol
and give the argument to                             
   make the protocol light-weight
   
You could enhance the security with minimal cost by including a key
(cf. e.g. RFC 2890) in the IP multicast traffic encapsulation format to
prevent network relays resulting in unwanted traffic to the end-user.

---

Section 6.2

   The AMT protocol provides no means for detecting or
   defending against a man-in-the-middle attack - any such functionality
   must be provided by multicast receiver applications through
   independent detection and validation of incoming multicast datagrams.

You might at least tell us what action you recommend if the receiver 
detects such a problem.

This is an exceptionally well written document, and was generally easy to understand.  Ron, thanks for fixing my DISCUSS point in an RFC Editor note.  What remain are a few non-blocking comments.  I think that addressing these will make the document a little better; feel free to chat with me about them if you like.

-- Section 4 --
This may be implicit in what the paragraph in Section 4 says, and perhaps Sections 4.x and 5.x are entirely consistent and no one will find any errata, but there's a lot here, and just in case there's something we don't catch...

...might it be reasonable to add a sentence such as this to the paragraph in Section 4?: "If anything in Section 4 is inconsistent with or contradictory to something in Section 5, the text in Section 5 is definitive."

-- Throughout Section 5 --
You've mostly consistently used the phrase "IANA-assigned AMT port number" to represent port 2268 [Section 7.3].  Mostly, except for the following:

5.1.5 uses "IANA-assigned AMT UDP port number" (adds "UDP")
5.2.3.4.2 uses "IANA-assigned UDP port number" (omits "AMT" and adds "UDP")
5.3.3.6 uses "IANA-assigned port" (omits "AMT" and "number")

It's probably useful to fix those three so that all uses are exactly the same.  Also, a "(see Section 7.3)" at the first instance, in Section 5.1.1, wouldn't be bad.

-- Sections 5.2.3.4.5, 5.2.3.5.6, and 5.3.6 --
These all refer to "a cryptographically secure pseudo random number generator."  Would they benefit from an informative reference to RFC 4086?

-- Section 5.3.5 --

   A Response MAC is produced by a hash digest computation.  A Response
   MAC value is computed from a Request message for inclusion in a
   Membership Query message, is computed from a Membership Update
   message to authenticate the Response MAC carried within that message,
   and is computed from fields in a Teardown message to authenticate the
   Response MAC carried within that message.

I had to read this a few times to parse it correctly.  Once I got it, I found that there's nothing wrong with it... but maybe we can make people work less hard this way?:

NEW
   A Response MAC is produced by a hash digest computation.  A Response
   MAC value is computed in three situations: from a Request message,
   for inclusion in a Membership Query message; from a Membership Update
   message, to authenticate the Response MAC carried within that message;
   and from fields in a Teardown message, to authenticate the Response
   MAC carried within that message.
END

   Gateways treat the Response MAC field as an opaque value, so a relay
   implementation may generate the MAC using any method available to it.
   The hash function RECOMMENDED for use in computing the Response MAC
   is the MD5 hash digest [RFC1321], though hash functions or keyed-hash
   functions of greater cryptographic strength may be used.

Why is this a 2119 "RECOMMENDED"?  Is there any reason the *protocol* cares what hash algorithm is used?

-- Section 5.3.3.3 --

   If a relay supports the Teardown message, it MUST set the G-flag in
   the Membership Query message and return the source IP address and UDP
   port carried by the Request message in the corresponding Gateway IP
   Address and Gateway Port Number fields.  If the relay does not
   support the Teardown message it SHOULD NOT set these fields as this
   may cause the gateway to generate unnecessary Teardown messages.

What reason might a relay have for violating that SHOULD NOT?  Why would a relay that does not support Teardown sometimes need to set those fields, such that "SHOULD NOT" (rather than "MUST NOT") is necessary?

-- Section 5.3.3.4 --

   A relay MUST maintain some form of group membership database for each
   endpoint.  The per-endpoint databases are used update a forwarding
   table containing entries that map an (*,G) or (S,G) subscription to a
   list of tunnel endpoints.

   A relay MUST maintain some form of group membership database
   representing a merger of the group membership databases of all
   endpoints.  The merged group membership database is used to update
   upstream multicast forwarding state.

   A relay MUST maintain a forwarding table that maps each unique (*,G)
   and (S,G) subscription to a list of tunnel endpoints.  A relay uses
   this forwarding table to provide the destination address when
   performing UDP/IP encapsulation of the incoming multicast IP
   datagrams to form Multicast Data messages.

I don't really want to pick on these too much, mostly because I can't imagine how *else* you might do this other than maintaining databases/tables, but...

Strictly speaking, the 2119 keywords should be calling out protocol requirements, not implementation methods.  It seems that the requirements are actually in the second sentence of each paragraph, and the MUSTs should be attached to those.  I'll use the second one as an example; perhaps this?:

NEW-maybe
   A relay MUST be able to update the upstream multicast forwarding
   state [a little more is needed here].  This is typically done by
   having the relay maintain some form of group membership database
   representing a merger of the group membership databases of all
   endpoints.
END

I would prefer it if you could re-cast each of these three paragraphs to attach the MUST to the actual protocol requirement, and talk about databases and forwarding tables as exemplary implementations (rather than attaching the MUST to the implementation).

That said, I'll remind you that this is a non-blocking comment, and if you think it will make the spec more awkward or less clear, then please don't do that.

1.
From this figure ...

  Isolated Site  |     Unicast Network    |  Native Multicast
                 |       (Internet)       |
                 |                        |
                 |                        |
                 |    Group Membership    |
      +-------+ ===========================> +-------+ Multicast +------+
      |Gateway|  |                        |  | Relay |<----//----|Source|
      +-------+ <=========================== +-------+           +------+
                 |     Multicast Data     |
                 |                        |
                 |                        |

                     Figure 1: Basic AMT Architecture

... I was not sure whether the left part of the gateway was IP unicast of multicast.
It's only when I saw the following figure that I understood. 

                  Gateway                         Relay

                    General _____         _____
        ___________  Query |     |       |     | Query  ___________
       |           |<------|     |       |     |<------|           |
       | Host Mode |       | AMT |       | AMT |       |Router Mode|
       | IGMP/MLD  |       |     |  UDP  |     |       | IGMP/MLD  |
       |___________|------>|     |<----->|     |------>|___________|
                    Report |     |       |     | Report
                Leave/Done |     |       |     | Leave/Done
                           |     |       |     |
       IP Multicast <------|     |       |     |<------ IP Multicast
                           |_____|       |_____|

               Multicast Reception State Managed By IGMP/MLD

It might be better to clarify it earlier in the draft

I didn't have time to do a full review, but did check on previous comments from Sean Turner to see if they were addressed.  I think it would be very helpful to address them, so a little additional info is given here on sections.  I think they were meant to fit in with Stephen's #2 discuss, I think.

From Sean:
a. [RFC6151] recommends against the use of MD5 as you've documented it.  If you
need any kind of collision resistance MD5 is inappropriate to use.  If you
don't care about collisions resistance, then I think you need to explicitly
state that in the security considerations.  MD5 is okay to use in an HMAC
though, but there are better choices out there for "new" protocols.

Reference to Sean's comment with sections:
b. It doesn't appear that Sean Turner's comment on nonce creation was addressed in 5.2.3.4.5 and 5.2.3.5.6
A reference to the RFC he mentioned would be helpful.  Here is Sean's comment:

[RFC4949]:

   $ nonce
      (I) A random or non-repeating value that is included in data
      exchanged by a protocol, usually for the purpose of guaranteeing
      liveness and thus detecting and protecting against replay attacks.
      (See: fresh.)

c. Again, from Sean's review, it looks like protections of the secret key were not added in section 5.3.6.  I think this is important.

Sean's #4: I don't see a reference to RFC4086?

I have one small clarification to ask about.  In section 5.3.3.4, in
reference to the text:

   The IGMP and MLD protocol specifications indicate that senders SHOULD
   use a link-local source IP address in message datagrams.  This
   requirement must be relaxed for AMT because gateways and relays do
   not share a common subnet.

is the requirement being relaxed that senders use a source IP address
of greater than link-scope or that the the relay IGMP and MLD
implementations accept a message with a link-local source IP address
from a sender that is not on-link?

I couldn't find where the document explicitly calls out how to represent the IP addresses in the binary fields - you almost certainly intend for them to be in network-byte-order, but if it's not already explicit in the document, please make it so.

Are there any considerations that the document should call out for administrators for making the transition when the network from which hosts had been using AMT to reach content is given native multicast connectivity?

  The reference to RFC 1321 should be informative (not normative).

  Please consider the editorial suggestions in the Gen-ART Review
  by Mary Barnes on 14-Dec-2012.  The review can be found here:
  http://www.ietf.org/mail-archive/web/gen-art/current/msg07993.html

0) I agree with Martin's 4th discuss (the security one).

1) I agree with Stephen's 1st discuss also.

2) I also agree with Stephen's 2nd discuss, but I've got a bit more: 

a) [RFC6151] recommends against the use of MD5 as you've documented it.  If you need any kind of collision resistance MD5 is inappropriate to use.  If you don't care about collisions resistance, then I think you need to explicitly state that in the security considerations.  MD5 is okay to use in an HMAC though, but there are better choices out there for "new" protocols.

b) If you're going to retain the secret key, then some words about protecting the secret are needed.  We can revisit this after the dust has settled on Stephen's discusses.

3) And on his "nonce" comment, yeah I really think it's not much of a nonce [RFC4949]:

   $ nonce
      (I) A random or non-repeating value that is included in data
      exchanged by a protocol, usually for the purpose of guaranteeing
      liveness and thus detecting and protecting against replay attacks.
      (See: fresh.)

4) s5.2.3.4.5/s5.2.3.5.6 and s5.3.6: Add a normative reference to RFC 4086 for randomness requirements.  Put it in the sentence that talks about the pseudo-random number generator.  It's pretty much the standard motherhood and apple pie  statement when it comes to PRNGs.

5) s4.1.3.1: r/is a architectural/is an architectural

6) s4.2.1.2 and elsewhere: r/private secret/secret (secrets are private :)

7) s4.2.2.3: So this is probably nit picking, but isn't I-D.ietf-6man-udpchecksums "the" solution not "a" solution as it's about to be a PS?

8) s5.2.3.4.2/s5.2.3.5.2: Would be good to provide a pointer to the state timers so folks will know how long they need to keep the nonce.

9) s5.3.6: WRT retention, shouldn't the prior secret key be kept until after you start using the new key?  App A talks about reauthenticating with the old key?

10) References:

a) Normative:

Pretty sure that in addition to 1321 being normative the following should also be normative:

I-D.ietf-6man-udpchecksums, 2336, 2710 - Even if these are SHOULD/MAY then it's a normative reference.  And, you place requirements on IGMPv2 MLD.  See IESG statement on informative/normative references.  Or, were you thinking the IGMPv3 implementation must support v2 Membership Report & v2 Leave Group in 3376 so you'd leave it information here?  I guess same for MLDv2 saying which bits of MLDv1 must be supported?.

RFC 2119 - Pretty sure this is always normative when used.

b) Unused references:

  == Unused Reference: 'RFC0768' is defined on line 3366, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4605' is defined on line 3385, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC2104' is defined on line 3418, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3053' is defined on line 3439, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3056' is defined on line 3442, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3068' is defined on line 3445, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC3973' is defined on line 3452, but no explicit
     reference was found in the text

  == Unused Reference: 'RFC4760' is defined on line 3464, but no explicit
     reference was found in the text

Thanks for handling my discuss points (and apologies for
being slow to check the new text before you posted -18).

I didn't check if these comments are still relevant for -18 but
have left them here just in case.

- 11 years. Wow! Kudos for being persistent!

- p11, in the figure (my ascii-art sympathies btw;-), why is
the application dealing with multicast data via UDP only?

- Its not that common to have a field called a nonce and yet
have that sent in multiple messages. Maybe this is more a kind
of session id?

- 5.1.2 - it'd have been nicer to have a length field for the
nonce or relay address so that you could vary the nonce length
without confusing matters. Seems like there're enough unused
bits to do that if you wanted.

- 5.1.5/5.1.6: What if the encapsulated packet is bigger than
the MTU, isn't that a problem?

- 5.1.6: Oughtn't you say something about congestion and being
TCP friendly?  

- Section 6: I always think that trying to be "as secure as
<<some insecure thing>>" is a bad goal to select.

- A.1 and 5.3.5 show MD5 inputs in different orders. They ought
be the same.

I fully agree with the issues in Martin's DISCUSS.