Re: [AVT] Token-based port mapping approach

draft-ietf-avt-rtcp-port-for-ssm is about the port where multicast RTCP is sent. It does not have anything to do with the unicast session. It is declarative.

-acbegen

> -----Original Message-----
> From: gerard.babonneau@orange-ftgroup.com [mailto:gerard.babonneau@orange-ftgroup.com]
> Sent: Friday, July 16, 2010 6:19 AM
> To: Ali C. Begen (abegen)
> Cc: avt@ietf.org; Dan Wing (dwing); draft-babonneau-avt-ssrc-mux-for-port-mapping@tools.ietf.org
> Subject: RE: [AVT] Token-based port mapping approach
> 
> Hy,
> 
> My proposal is not only about security, but also on RTP/RTCP multiplexing.
> 
> I read draft-ietf-avt-rtcp-port-for-ssm and I wonder if the same SDP problem also occurs in sharing some RTCP sessions
> between P3 and P4 (see message below), both in draft-ietf-avt-ports-for-ucast-mcast-rtp and draft-begen-avt-token-for-
> portmapping. In order to simplify, my proposal is to use a single port for all unicast sessions, as long as inconsistensy with
> token or cookie has not been proved.
> 
> Token looks me simple, as I understand it, because it allows NAT changes port without blocking the response. Am I right? This
> may be optimized when the receiver send rare requests (example: less than 1 per hour when looking at an entire movie on a
> hight quality ADSL line).
> 
> Regards,
> 
> Gérard BABONNEAU
> 
> -----Message d'origine-----
> De : Ali C. Begen (abegen) [mailto:abegen@cisco.com]
> Envoyé : lundi 12 juillet 2010 17:49
> À : BABONNEAU Gerard RD-MAPS-REN
> Cc : avt@ietf.org; Dan Wing (dwing); MARJOU Xavier RD-CORE-LAN; STEPHAN Emile RD-CORE-LAN
> Objet : RE: [AVT] Token-based port mapping approach
> 
> 
> 
> > -----Original Message-----
> > From: gerard.babonneau@orange-ftgroup.com
> > [mailto:gerard.babonneau@orange-ftgroup.com]
> > Sent: Monday, July 12, 2010 11:20 AM
> > To: Ali C. Begen (abegen)
> > Cc: avt@ietf.org; Dan Wing (dwing); xavier.marjou@orange-ftgroup.com;
> > emile.stephan@orange-ftgroup.com
> > Subject: Re: [AVT] Token-based port mapping approach
> >
> > Now we have 3 solutions. All of them use both session-multiplexing and
> > ssrc_multiplexing, as defined in rfc 4588. I can resume it in the following figure.
> > Definitions and symbols:
> > - RT(c)P_med is the media streaming.
> > - RTCP_fb is requests and responses for extended service (as RAMS messages or retransmission request).
> > - RT(c)P_ext is the extented service ( RET or FCC) in response to RTCP_fb.
> > - arrows mean the direction of messages, with server on the left side and terminal on the right side.
> >
> >
> >
> >
> >     P1 (mcast)   P2 (mcast)   P3 (ucast)   P4 (ucast)
> >
> > draft-ietf-avt-ports-for-ucast-mcast-rtp
> >     RTP_med      RTCP_med     RTCP_med
> >     -------->    -------->    <--------
> >                               RTCP_fb     RTCP_fb
> >                               <--------   -------->
> >                                           RTP_ext
> >                                           -------->
> >                                           RTCP_ext
> >                                           <------->
> > draft-begen-avt-token_for-portmapping
> >     RTP_med      RTCP_med     RTCP_med
> >     -------->    -------->    <--------
> >                               RTCP_fb
> >                               <------>
> >                               RTP_ext
> >                               -------->
> >                               RTCP_ext   RTCP_ext
> >                               -------->  <--------
> >
> > draft-babonneau-avt-ssrc-mux-for-port-mapping
> >     RTP_med      RTCP_med     RTCP_med
> >     -------->    -------->    <--------
> >                               RTCP_fb
> >                               <------->
> >                               RTP_ext
> >                               -------->
> >                               RTCP_ext
> >                               <------->
> >
> >
> > This figure show that, a priori, multiplexing may have several
> > configuration that depend on cookie, token or nothing, with impacts on security and NAT issues.
> >
> > In my mind, NAT and security issues have pros and cons that depend on the application context.
> 
> As it was made very clear during the breakout sessions and RAMS wglc, a proposal without the necessary protection against
> the bandwidth attacks will not stand a chance to be approved by IESG.
> 
> > So, if every people agree, I suggest to have a single draft that gives
> > a set of solutions that fit many services contexts.
> 
> I am not in favor of having multiple different options for implementation. We should discuss all but at the end, we should
> stick with one of them.
> 
> -acbegen
> 
> > Regards,
> >
> > Gerard BABONNEAU
> >
> >
> >
> > Ali C. Begen (abegen) a écrit :
> >
> > 	As mentioned in a recent email
> > (http://www.ietf.org/mail-archive/web/avt/current/msg13225.html)
> > we wrote up a simpler approach to port mapping. Unfortunately we
> > missed the -00 deadline but considering the similarities with
> > draft-babonneau-avt-ssrc-mux-for-port-mapping and Tom Van Caenegem's
> > description in Anaheim, it seems useful for the WG to consider if this Token-based approach is superior to the Cookie-based
> approach (draft-ietf-avt-ports-for-ucast-mcast-rtp).
> >
> > 	Until submission re-opens, the draft can be reached from:
> >
> > http://ali.begen.net/files/draft-begen-avt-token-for-portmapping-00.tx
> > t
> >
> > 	-acbegen
> > 	_______________________________________________
> > 	Audio/Video Transport Working Group
> > 	avt@ietf.org
> > 	https://www.ietf.org/mailman/listinfo/avt
> >
> >
> >