Re: [AVT] Revised Consensus call - On Token approach for draft-ietf-avt-ports-for-ucast-mcast-rtp

[Colin Perkins <[e-mail]>]

On 12 Oct 2010, at 06:23, Van Caenegem, Tom (Tom) wrote:

> Hi Colin,
>
> See below,
> Tom
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf  
> Of Colin Perkins
> Sent: maandag 11 oktober 2010 18:51
> To: Roni Even
> Cc: DRAGE, Keith (Keith); 'IETF AVT WG'; 'Dan Wing'
> Subject: Re: [AVT] Revised Consensus call - On Token approach for  
> draft-ietf-avt-ports-for-ucast-mcast-rtp
>
> On 8 Oct 2010, at 09:47, Roni Even wrote:
>> There were some concerns about how we drafted the consensus call so I
>> would like to try and give it another try.  Sorry for the long  
>> message
>> which I hope will clarify what are the proposed options. We would  
>> like
>> to get feedback by October 18th.
>>
>>
>> The Port Mapping Between Unicast and Multicast RTP Sessions described
>> in
>> http://tools.ietf.org/html/draft-ietf-avt-ports-for-ucast-mcast- 
>> rtp-02
>> was discussed for a couple of IETF meeting and on the list. The
>> initial approach that was agreed after we had a breakout session in
>> previous IETF meetings was to use a cookie based solution even though
>> it required more messages and you needed a cookie for every RTP
>> session.
>>
>> Before the last IETF meeting there were two proposals to update the
>> solution to a token based approach.
>>
>> In the token approach:
>> - Tokens are port-independent (cookies are port-dependent) and only
>> depend on the client's IP. That is, once a client gets its token, it
>> can use it with any of its ports and with any Feedback Target.
>> - Tokens address the concern raised by Magnus
>> (http://www.ietf.org/mail-archive/web/avt/current/msg12617.html
>> )
>> - No need for keep-alives
>>
>> We had a discussion in Maastricht and the outcome is in the meeting
>> minutes http://www.ietf.org/proceedings/78/minutes/avt.txt (see the
>> section on draft-begen-avt-token-for-portmapping). The token draft  
>> has
>> Dan Wing (who is also BEHAVE co-chair) as a co-author and he looked  
>> at
>> the solution verifying that it will work well with NATs
>>
>>
>> At the meeting the preference was for a token based solution but  
>> there
>> are were two approaches discussed.
>>
>> 1. Use the token only solution
>>
>> 2. Use a combination when if the request has only an IP address the
>> response will be a token and if it will have both IP address and port
>> the response will be a  cookie.
>>
>> According to the minutes the support was for the second approach.
>> The major reason was a concern that carrier grade NATs can allocate
>> more than one IP address as the public address.
>>
>> The authors of
>> http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01
>> suggest that they addressed the concerns about the token only  
>> solution
>> (see section 9 of the draft) and prefer to have a token only  
>> solution.
>> This is a change from the meeting minutes and this is the reason for
>> the second question in this consensus call.
>>
>> So here are two questions for the group !!!
>>
>> 1. Do the people in the mailing list support the proposal to use a
>> token based solution instead on the cookie one. (this was the
>> preference in the consensus call in Maastricht) and we would like to
>> confirm it on the list.
>>
>> 2. We have two options for the token approach, please give your
>> preferences.
>>
>> 2.1 Token only solution as proposed in
>> http://tools.ietf.org/html/draft-begen-avt-token-for-portmapping-01
>> 2.2 Token + cookie, in this case if the request will include only IP
>> address the response is a token, if it also includes a port it will  
>> be
>> a cookie. This approach is for cases were the NAT may use more than
>> one IP address for mapping a local address.
>>
>>
>> Please respond even if you did it on the previous consensus call.
>
>
> The approach in draft-begen-avt-token-for-portmapping-01 looks to be  
> sufficient to allow a server to determine that multiple requests  
> come from the same client, provided the client isn't multi-homed and  
> isn't sharing an IP address with other clients. The problem  
> statement is not clear enough for me to be sure if that's sufficient.
>
> If it were important to do so, the server could distinguish multiple  
> clients sharing the same IP address if each client supplied a random  
> nonce that was taken into account when generating the token in  
> addition to the client's IP address. This may be an issue with use  
> of fractional IP addresses in future, and so might be something to  
> consider adding.
>
>
> TOM: I think this is a good idea. The SSRC of the client associated  
> with the SSM RTP session that is present in the portmapping request  
> message could be used for that purpose (hence token is determined by  
> server on the basis of IP address, time stamp  and client SSRC)

No, because the SSRC can change, and this should be persistent per  
client.


> Distinguishing multi-homed clients, or clients where requests come  
> from several different IP addresses, is more complex. Is this an  
> issue, or is it sufficient to assume that a client requests a new  
> token when changing the address it uses?
>
> TOM: IMO that will do..I think it is bad practice if a network stack  
> on a host device/ NAT device allocates different IP addresses  
> towards a application/end-host
>
> I'd also like to note that the port mapping operation is independent  
> of the RAMS drafts. It would be good if the draft the group ends up  
> with is written as a standalone mechanism, with RAMS described as  
> one example use case, rather than being written in a RAMS-specific  
> manner as are the current drafts.
>
> TOM: The text is meant to be (only) applicable to scenarios building  
> on SSM sessions with unicast feedback, no? We wanted a fast -inband-  
> way for a client to communicate the client receive port for a  
> unicast connection that is linked to such a SSM. In that case, the  
> text is sufficiently generic (e.g. RAMS is not even mentioned in the  
> text, whereas the example is about retransmissions). I take it that  
> any other parameter signaling (port, any attributes,..) for any  
> other scenario needs to leverage the SDP offer-answer model.
>
> Cheers,
> Colin
>
>
> -- 
> Colin Perkins
> http://csperkins.org/
>
>
>
> _______________________________________________
> 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



-- 
Colin Perkins
http://csperkins.org/