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

["DRAGE, Keith (Keith)" <[e-mail]>]

(As WG chair)

Magnus can you indicate which of these issues you now believe are closed, and which therefore are still open and needing discussion.

Ali: When you see a response from Magnus, can you open separate threads on these and get them closed to the satisfaction of the WG.

Members of the WG, please chime in - we'd like to get these closed and issue a new version of the draft by the 10th.

regards

Keith

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Ali C. Begen (abegen)
> Sent: Monday, November 29, 2010 3:37 PM
> To: Magnus Westerlund;
> [e-mail]; IETF AVT WG
> Subject: Re: [AVT]
> draft-ietf-avt-ports-for-ucast-mcast-rtp-04: Review Comments
>
> 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
> _______________________________________________
> Audio/Video Transport Working Group
> [e-mail]
> https://www.ietf.org/mailman/listinfo/avt
>