Subject: [AVT] Token-based port mapping approach

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 8 Jul 2010 09:26:12 -0700

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.txt 

-acbegen

---

From: <[email-masked]>
Date: Mon, 12 Jul 2010 17:20:10 +0200

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.
 
So, if every people agree, I suggest to have a single draft that gives a set of solutions that fit many services contexts.

Regards,
 
Gerard BABONNEAU

Ali C. Begen (abegen) a écrit : 

	
	-acbegen
	_______________________________________________
	Audio/Video Transport Working Group
	[email-masked]
	https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Mon, 12 Jul 2010 08:49:20 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, July 12, 2010 11:20 AM
> To: Ali C. Begen (abegen)
> Cc: [email-masked]; Dan Wing (dwing); [email-masked]; [email-masked]
> 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:

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

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
 
> 	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).
>

---

From: <[email-masked]>
Date: Fri, 16 Jul 2010 12:18:37 +0200

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:[email-masked]] 
Envoyé : lundi 12 juillet 2010 17:49
À : BABONNEAU Gerard RD-MAPS-REN
Cc : [email-masked]; Dan Wing (dwing); MARJOU Xavier RD-CORE-LAN; STEPHAN Emile RD-CORE-LAN
Objet : RE: [AVT] Token-based port mapping approach

> From: [email-masked] 
> [mailto:[email-masked]]
> 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:
> 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.
> 

> So, if every people agree, I suggest to have a single draft that gives 
> a set of solutions that fit many services contexts.

-acbegen
 
> 	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).
>

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Fri, 16 Jul 2010 10:15:06 -0700

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

> Sent: Friday, July 16, 2010 6:19 AM
> Cc: [email-masked]; Dan Wing (dwing); [email-masked]
> Subject: RE: [AVT] Token-based port mapping approach
> 
> Hy,
> 
> 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
> 
> 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.
> 
> > 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).
> >