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

> -----Original Message-----
> From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of gerard.babonneau@orange-ftgroup.com
> Sent: Thursday, September 16, 2010 10:30 AM
> To: DRAGE, Keith (Keith); IETF AVT WG
> Cc: MARJOU Xavier RD-CORE-LAN; STEPHAN Emile RD-CORE-LAN
> Subject: Re: [AVT] Consensus call - Token approach withindraft-ietf-avt-ports-for-ucast-mcast-rtp
> 
> We are ok to merge token and cookie draft.
> 
> But it could be useful to have options according to security issues:
> 1) Possibly nothing, if the transaction is all inside a very secure network (under the operator's responsability).
> 2) about token we would prefer a slightly modified approach (simpler and more powerful), by having the token based on
> SSRC. When receiving a RTCP FB to request a token (message to define), the server ascertains the token from the SSRC of
> packet sender and the SSRC of the media sender as defined in RFC 4585. Because (1) the SSRC of packet sender never
> changes in a session and (2) the token includes neither the port number nor the IP address, it is fully compatible with all NAT

How so? When a client is joining a new SSM session, its SSRC may very well collide with other receivers already existing in that session. Relying on SSRC is not possible since SSRC can change any time.

-acbegen

> processing and NAT configuration changes, and a single exchange at starting the session is enough in all cases. An additional
> processing may be (rarely) necessary when two receivers of the same multicast stream choose a same SSRC packet sender
> value.
> 
> 
> Regards,
> 
> Gerard BABONNEAU,
> Xavier MARJOU
> Emile STEPHAN
> 
> 
> 
> DRAGE, Keith (Keith) a écrit :
> 
> 	(As WG cochair)
> 
> 	As part of the RAMs work we have a dependent draft in draft-ietf-avt-ports-for-ucast-mcast-rtp. This provides a
> cookie based approach to port mapping. See:
> 
> 	https://datatracker.ietf.org/doc/draft-ietf-avt-ports-for-ucast-mcast-rtp/
> 
> 	At IETF#78 we discussed a token based approach, which could be used in some circumstances as an alternative
> mechanism for solving the problem, and which has less overhead than the cookie based approach. We asked Ali to write this
> up as a draft so that people could discuss something written down, and he has duly done this as draft-begen-avt-token-for-
> portmapping-01
> 	available at:
> 
> 	https://datatracker.ietf.org/doc/draft-begen-avt-token-for-portmapping/
> 
> 	This message therefore requests the working group to come to consensus on one of the following two alternatives:
> 
> 	1)	To incorporate material from draft-begen-avt-token-for-portmapping-01 into draft-begen-avt-token-for-
> portmapping-01 so that the draft describes a combined token / cookie approach.
> 
> 	OR
> 
> 	2)	To proceed with draft-begen-avt-token-for-portmapping-01 with the current technical contents as the solution.
> 
> 	Please reply to this message with your positions. Please feel free to respond with questions for additional clarification
> if you need that clarification to make a decision.
> 
> 	Please respond by close of business on Friday 17th September at the latest in order for a WG decision to be made.
> 
> 	This call is not about the final form of the words, so while you are welcome make make proposals in that direction,
> please keep those to separate threads.
> 
> 	regards
> 
> 	Keith
> 	_______________________________________________
> 	Audio/Video Transport Working Group
> 	avt@ietf.org
> 	https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 