[AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments

[Magnus Westerlund <[e-mail]>]

Hi,

I have done a review of the document and have a number of comments. The
upper part will contain technical or larger editorial comments, while
the lower parts will be minor editorial comments.

T1. Section 1. I am missing a discussion of the signalling aspects for
the applications using these tools. Declarative service signalling seems
to be one of the reasons for doing dynamic session creation.

T2. Section 3. I am missing an explicit list of the assumptions on what
is in place around the service when describing the port mapping.

T3. Section 3.2, page 9, bullet 3:
3.  If the client does not have a valid Token:

How does a client determine if it has a valid token or not. To my
understanding the following things needs to be done.

First, it needs to check if it has a token for the server + port
specified by the session description. May be from a previous session.
Secondly, it checks if it hasn't expired due to age.

T4. Section 4. IP address for token request.

It is not clear on how the IP address for the Token Request is
determined. Is this the C=? I think there is a good point in allowing
optional specification of the address information in this SDP attribute,
similar to the a=rtcp attribute.

T5. Section 4. Offer/Answer behavior for the "a=portmapping-req"
attribute. Having learned my lessong with other attributes. Lets define
the SDP offer/answer behavior for this attribute already now.

T6. Section 4. Where should the signalling aspects of the port-mapping
be normatively discussed. It might be that Section 4, should be expanded
to cover the signalling requirements and their implementation using SDP
both declarative and offer/answer.

T7. Section 5.1: Random Nonce. It is not clear when a client should
generate a new nonce. My guess would be for each new Token request, i.e.
every time a new Token needs to be acquired, but that isn't stated.

T8. Section 5.2 etc: Fixed length token.

I think this solution should abandon a fixed length token, and instead
use a variable length token. I think there are a number of reasons for that:

1. Crypto-agility: If we specify that the crypto hash length is to be
128 bits, then that doesn't prevent using another hashing mechanism, but
it prevents going for a stronger protection by increasing the hash
output length. As it is likely that a key will be in long term usage
there is potential for needing quite strong keys. This as this solution
is possible to do off-line attacks. Do a token request, capture the
material going into the hash, then go find the key.

2. Freedom of implementing the token according to the needs of the
implementation. As there only need to be agreement between all the
servers using the same token. But an example implementation is good.

3. There is no space for indication of which key has been used, which
makes key-roll over slightly more difficult. Using only the expiration
time for which key should be used, is possible but puts requirements on
implementation to do things in the right order.

4. Possibility to include additional information in the token, including
the address for better error detection.

Thus I would recommend that we allow for a variable token, and with a
recommended way of generating the token. We do need to be clear on the
security requirements on the token.

T9. NTP values: I think some mentioning of the epochs for the NTP clock
is needed. 2032 isn't that far off, and the roll over needs to be handled.

T10. Section 5.4:
Why no error code in the Token Failure message. To me it seems possible
that a server can separate a couple of different failures and report
back on them:

- Expired token
- Missmatch of address (Either by keeping state or include the address
in the token)
- Missmatch in Nonce.
- Adminstratively expired token.

T11. Section 5.4: Why isn't the "associated Nonce" included in the error
response? Either that or the token needs to be included so that the
client knows which token that didn't work. This as a client may have
multiple outstanding requests and not necessarily with the same token.

T12. Section 6. More comments on token generation:
a. Missing recommended expiration time, or at least what is a reasonable
token life time.

b. Make it clear that the key do need to be well generated, and not use
Null keying of the HMAC.

c. Why not recommend SHA-256? Even if HMAC-SHA1 isn't broken yet, it
starting to be an aging crypto mechanism.

T13. Section 10.
I am lacking a discussion of the security issues around the token
itself. As I see it factors as how long the server uses a key, key-roll
over requirements, off-line attack possibility and crypto agility all
needs discussion.

Then I am missing the signalling aspect vulnerabilities on this solution
and the requirement that puts on the signalling infrastructure.




E1: Abstract: "This document presents a port mapping solution that
allows RTP
   receivers to choose their own ports for an auxiliary unicast session
   in RTP applications using both unicast and multicast services
   (almost) without the need for retrieving pre-authorization."

"I would reformulate the last part of the sentence, i.e. from
"(almost)". There is no meaning in differentiating between the solution
when this is the one we are doing.

In addition maybe try to make the abstract a bit more complete in what
it the document covers.

E2. Section 1, second paragraph: I would include NATs as being actively
considered and a reason why dynamic mappings are to be preferred.

E3. Section 1, fourth paragraph:
   An example scenario is where the RTP packets are distributed through
   source-specific multicast (SSM) and a receiver sends unicast RTCP
   feedback to a local repair server (also functioning as a feedback
   target) [RFC5760] asking for a retransmission of the packets it is
   missing, and the local repair server sends the retransmission packets
   over a unicast RTP session [RFC4588].

I would do the following changes to the above:

   An example scenario is where the RTP packets are distributed through
   source-specific multicast (SSM) and a receiver sends unicast RTCP
   NACK feedback to a local repair server (also functioning as a
   ^^^^

   unicast RTCP feedback
   ^^^^^^^^^^^^
   target) [RFC5760] asking for a retransmission of the packets it is
   missing, and the local repair server sends the retransmission packets
   over a unicast RTP session [RFC4588].

E4. Section 3.2: Instead of jumping straight into the example I would
spend at least one paragraph on a high level description of what is
assumed to be happening in generic wording. Maybe something like:

When an RTP receiver transmits an RTCP feedback message where it expects
the server to send unicast RTP traffic to the receiver, it needs to
include the acquired token from step one in a RTCP Token verification
request message. The server receives the RTCP compound message and
verifies the token. The server can then assume that the RTCP message
requesting a particular service, such as retransmission or Rapid
Acquisition of a Multicast session, is legit. An existing or new unicast
RTP session is used to fulfill the request.

E5. Page 8, bullet "1":
 If c0=c1, the occasional (periodic) RTCP receiver
          reports sent from port c0 (for the multicast session) will
          ensure the NAT does not time out the public port associated
          with the incoming unicast traffic to port c1.

I would suggest the following edit:

If c0=c1, the occasional (periodic) RTCP receiver
          reports sent from port c0 (for the multicast session's
          RTCP port P3) will
          ^^^^^^^^^^^^
          ensure the NAT does not time out the public port associated
          with the incoming unicast traffic to port c1.

E6. Page 9,
2.  The client determines its port numbers (*c0, *c1 and *c2).

I would change it to:
2.  The client selects its local port numbers (*c0, *c1 and *c2).

E7. section 3.2:
2The server generates an opaque encapsulation (i.e., the
           Token) that conveys client's IP address information using a
           reversible transform only known to the server.  For details,
           see Section 6."

There seems to be a mismatch between this text and Section 6. Also see
tech discussion about the token.

E8. Section 3.2, page 10, bullet 5:
"Note that in the
       unicast session the RTP and RTCP packets MUST be multiplexed on
       the (same) port c1."

I would try to improve the clarify on the directionality in the traffic
in this paragraph, especially the above sentence:

Note that in the
       unicast session traffic from the server to the receiver the RTP
and RTCP packets MUST be multiplexed, i.e. both RTP and RTCP sent from
P3 with the destination port c1'.

E9. Section 8. I think this section makes sense to include as a
sub-section under a signalling discussion section where high level
requirements, SDP extensions, SDP usages including O/A and then examples
are included.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------