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

[Magnus Westerlund <[e-mail]>]

Hi,

I have removed the things where we are in agreement.

Ali C. Begen (abegen) skrev 2010-11-29 16:37:
> 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".

I think the general requirements on what needs to be signalled is not
sufficiently well explained in the draft. Like the need for a unicast
session with the RTP configuration for what will be transmitted. The c=
address, etc.

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

To me it appears there is certain assumptions around the service when
using port mapping. That the service are highly dynamic around the the
unicast sessions, and also that it uses a more declarative style of
configuration.

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

Ok, or possibly your change plus:
"or the token has expired based on the time fields"?

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

The first step is about the servers address and port. It is how a
receiver determine if it can reuse a token or needs to get another one.
That is not described so that one can safely implement this. But I
assume you are of interest in reusing the token for example between all
TV channels a particular RS handles.

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

Or simply save the local clock when the token was received.

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

I think we should enable it as I find it likely that someone will use
such a setup. If the setup is a anything like homes with NATs and no
large scale NAT then I don't think there is likely that you will get
another IP address in the NAT. Even large scale NATs will do their best
to use the same IP address for the same underlying host.

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

NO! I think it is not that far fetched that you use SIP and O/A to
configure the receiver for a Multicast plus unicast service. For example
using SIP to invite you into a particular IP TV channel. Thus I think
there is a clear need to ensure that this works with O/A.

I tried to say, no you can't use O/A with this attribute, it has failed
miserably. So lets fix that, now rather than later when things don't
interoperate.

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

No, I think using SIP to tell a receiver to join a particular service is
very reasonable. In addition the focus of this comment is that the
signalling aspects aren't brought together in a good way discussing what
needs to be signalled.


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

More input is desirable on this.

> 
> Are you suggesting to keep section 6 as an example but not mandatory to follow?

I would keep it as it is a reasonable guidance on what the token need to
be for the basic functionality.

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

It is not that difficult. And RTP is being used and show no clear
indication of being reduced in importance after 16 years. The NTP roll
over is only 22 years away. Time to at least mention it. The new NTP
spec has discussion of epoch, so a short text saying. Please be aware
that NTP will roll over in 2036 and that you might need to handle this
eventually. RFC 5905, section 6 is the relevant reference.

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

So you are basically saying, if you get Token error, simply go request a
new one?

And you don't think there will be any difference in the client behavior
based on the reason.

Ok, I think I can live with that in the token verification step.
However, then I think we need something in the token request response
message that says, sorry, I can't give you a valid token. Otherwise the
server has no way of cleanly say no to a receiver that are not being
serviced. For example due to DoS from that address. Simply ignoring the
RTCP is clearly one possibility, but doesn't seem to be as clean as
saying  no explicitly. At least a few times.

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

Please note that this is the verification error message. I agree that a
sanely setup system you shouldn't use the same Feedback target
address+port shouldn't get RTCP messages related to different services
without them explicitly sharing the tokens. But, as currently defined
this is not strictly disallowed I think.

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

Ok, thanks for addressing my protocol paranoia.


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

I agree that part of this is the application. But there are also the
security angle of it. Thus I think some general discussion of this
should be had.

I think more long lived tokens that 24 hours is not needed. Then for
usage with a lot of turn over in the receiver population I would suggest
a much shorter timer, no longer than 1 hour.

And in the extreme case you need one use tokens.


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

Yes, I mostly agree. And SHA-1 is probably a good recommendation
currently. Because this needs to be a easily available algorithm. But if
we are going down the path of variable size tokens, then we can continue
using SHA-1 in the example solution and if it becomes an issue people
can roll new ones independently.

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

Ok.

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

Exactly, or c= attribute

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