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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 29 Nov 2010 15:37:39 +0100

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  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 29 Nov 2010 07:37:00 -0800

Hi Magnus,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Magnus Westerlund
> Sent: Monday, November 29, 2010 9:38 AM
> To: [email-masked]; IETF AVT WG
> Subject: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments
> 
> Hi,
> 

Yes, that is the primary use case. But, I am not sure whether I understand what you mean by "discussion of the signaling aspects".
 
> is in place around the service when describing the port mapping.

I am also not sure what you mean here. 
 
> 3.  If the client does not have a valid Token:

Actually, that line should say "if the client does not have a Token".
 
> Secondly, it checks if it hasn't expired due to age.

The client can only do one reliable check based on the relative exp time. The client's public IP may have changed and it cannot necessarily know this. 

So, naturally, the client knows from which server/port it received the token and should have started a timer upon receiving it. Then, it can compare it with the relative exp time.
 
> similar to the a=rtcp attribute.

The address is the feedback target address in the primary session, which equals to the address given in the C line for the unicast session (as you indicated).

Does it make any sense to have the token request message to be sent to a different address than the unicast source (which also means the token response could be sent by another entity)? This may break the Token actually since client's IP address might be different for different destinations, right?
 
> the SDP offer/answer behavior for this attribute already now.

I understand your concern about somebody else trying to use this attribute in an O/A setting in the future. But, if that were possible, we would not be needing this Token mechanism in the first place.

Instead, I suggest we make it clear in the document saying the O/A behavior MUST NOT be defined or used for this attribute.

> both declarative and offer/answer.

Relating to the previous comment, lets just define the declarative requirements and forbid the o/a.
 
> every time a new Token needs to be acquired, but that isn't stated.

Yes, correct, we should add this.
 
> security requirements on the token.

OK, I am neutral on this and we can certainly allow for variable-length Tokens but for that, we will need a length field (like a TLV element) to carry the Token back and forth. 

Are you suggesting to keep section 6 as an example but not mandatory to follow?
 
> is needed. 2032 isn't that far off, and the roll over needs to be handled.

Seriously, you think we will be using tokens at that time :) if so, I guess somebody will fix it for NTP and then we can rev the token draft at that time.
 
> - Adminstratively expired token.

I don't think the server can determine which component was the reason for verification failure. I.e., the server generates a new token based on the new input and it can only decide whether it is a match or not. If it is not, it cannot determine whether the nonce or the IP was to blame.

As for the expiration time, the client should not send such tokens anyway. If it does and it receives a failure message, the reason would be obvious.

Overall, I don't think we can (or need anyway to) specify the reason for failure.
 
> multiple outstanding requests and not necessarily with the same token.

Normally a client would not need to send multiple different requests to the same FTAp to get a token. If the client puts a different nonce in each request, yes, the tokens will be different but what is the point in doing that? One token is enough for the client.

So, I don't really see a need for this. Did I miss something you had in mind?

Adding the nonce or the token is not a big deal anyway, so lets add the Token to the failure message.
 
> a. Missing recommended expiration time, or at least what is a reasonable

Is not this really application specific? If you were asked to recommend one, what would you say?
 
> b. Make it clear that the key do need to be well generated, and not use

Ok.
 
> starting to be an aging crypto mechanism.

I don't have much to favor one over another. But, it is not like we are protecting your financial data. 

I would imagine you could spend less effort to hack into such a network to divert the traffic compared to hacking into somebody else's token. Remember that just stealing somebody else's token does not get you much.
 
> over requirements, off-line attack possibility and crypto agility all

I will let Dan respond to this.
 
> and the requirement that puts on the signalling infrastructure.

You mean if somebody messes with the portmapping-req attribute in the SDP?
 
>    NACK feedback to a local repair server (also functioning as a

We will get these fixed in the revision.

Cheers, acbegen.

> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt