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

["Van Caenegem, Tom (Tom)" <[e-mail]>]

Yes, you are right on SSRC. A dedicated random nonce will be required. 
Are you OK with my view on how wide (or narrow) the cookie method can be used?
Tom

-----Original Message-----
From: Colin Perkins [mailto:[e-mail]] 
Sent: dinsdag 12 oktober 2010 13:34
To: Van Caenegem, Tom (Tom)
Cc: Roni Even; 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 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/