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

["Ali C. Begen (abegen)" <[e-mail]>]

Hi Magnus,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Magnus Westerlund
> Sent: Monday, November 29, 2010 9:38 AM
> To: [e-mail]; IETF AVT WG
> Subject: [AVT] draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments
> 
> 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.

Yes, that is the primary use case. But, I am not sure whether I understand what you mean by "discussion of the signaling aspects".
 
> 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.

I am also not sure what you mean here. 
 
> T3. Section 3.2, page 9, bullet 3:
> 3.  If the client does not have a valid Token:

Actually, that line should say "if the client does not have a 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.

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

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

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.

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

Relating to the previous comment, lets just define the declarative requirements and forbid the o/a.
 
> 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.

Yes, correct, we should add this.
 
> 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.

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

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

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

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.
 
> T12. Section 6. More comments on token generation:
> a. Missing recommended expiration time, or at least what is a reasonable
> token life time.

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
> Null keying of the HMAC.

Ok.
 
> c. Why not recommend SHA-256? Even if HMAC-SHA1 isn't broken yet, it
> 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.
 
> 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.

I will let Dan respond to this.
 
> Then I am missing the signalling aspect vulnerabilities on this solution
> and the requirement that puts on the signalling infrastructure.

You mean if somebody messes with the portmapping-req attribute in the SDP?
 
> 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.

We will get these fixed in the revision.

Cheers, acbegen.

 
> 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]
> ----------------------------------------------------------------------
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt