Subject: [AVT] Questions about draft-babonneau-avt-ssrc-mux-for-port-mapping

From: Jonathan Lennox <[email-masked]>
Date: Tue, 6 Jul 2010 12:19:02 -0400

Hi -- I read draft-babonneau-avt-ssrc-mux-for-port-mapping, and I had some questions.

First of all, are you familiar with RFC 5576?  It allows explicit signaling of SSRC values in SDP.

Secondly, the archictecture you're recommending isn't clear to me.  Are you proposing that both the original streaming source, and the RAMS retransmission source, share the same (presumably multicast) RTP session?  This seems like it would be pretty straightforward to do, though the scaling characteristics could be problematic.

Or do you intend that the original (multicast) RTP session and the retransmission (unicast?) RTP session are distinct, but somehow share their transport addresses to simplify NAT traversal?  I don't see how that's possible -- unicast and multicast have inherently different IP addresses, of course.

-- 
Jonathan Lennox
Vidyo, Inc
[email-masked]

---

From: [email-masked]
Date: Wed, 07 Jul 2010 15:20:52 +0200

Hi,

First, of course we use explicit signaling of SSRC in SDP, even if we
do  not referenced 5576. Is it any other way for ssrc-multiplexing?

Secondly, each multicast session must always be independant, notably to
never introduce over-rate when multiplexing in the same IP multicast
address, and because the size of a multicast group may be huge. This is
critical for DSL lines. Using independant RTCP ports for multicast and
unicast RTP sessions needs to link sessions together at the application
layer.

Yes, multicast and unicast are distinct, and they do not share same
ranges values. In our idea, ssrc-multiplexing is a powerfull solution
that use a single unicast UDP port/address to multiplex all the
RTP/RTCP companion streams related to a RTP multicast one. Incoming multicast with NAT has
solutions. SDP can
provide IP address and port of a "Distribution Source" (or source2 in
draft). Unicast request from a receiver to Distribution source
naturally open NAT for the response. It provide information on the RTP
destination address and ssrc in RTCP FB messages (see rfc 4585) is
enough to link to the right multicast video session.

Regards,

Gérard BABONNEAU

Jonathan Lennox a écrit :

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Wed, 7 Jul 2010 08:11:21 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of gerard.babonneau@orange-
> ftgroup.com
> Sent: Wednesday, July 07, 2010 9:21 AM
> To: Jonathan Lennox
> Cc: [email-masked]; [email-masked]
> Subject: Re: [AVT] Questions aboutdraft-babonneau-avt-ssrc-mux-for-port-mapping
> 
> Hi,
> 
> First, of course we use explicit signaling of SSRC in SDP, even if we do  not referenced 5576. Is it
> any other way for ssrc-multiplexing?

But you realize that we cannot actually control what the incoming multicast sources will use for their SSRCs, right? This was extensively discussed during the RAMS draft. Initially, the RAMS draft also mandated the use of 5576 but now we removed it since in practice it may not work as expected.

If you look at the RAMS draft now, you will see that it uses session muxing.
 
> Secondly, each multicast session must always be independant, notably to never introduce over-rate when
> multiplexing in the same IP multicast address, and because the size of a multicast group may be huge.

Sure, nobody says ow.

> This is critical for DSL lines. Using independant RTCP ports for multicast and unicast RTP sessions
> needs to link sessions together at the application layer.

Yup.
 
> Yes, multicast and unicast are distinct, and they do not share same ranges values. In our idea, ssrc-
> multiplexing is a powerfull solution that use a single unicast UDP port/address to multiplex all the
> RTP/RTCP companion streams related to a RTP multicast one. Incoming multicast with NAT has solutions.
> SDP can provide IP address and port of a "Distribution Source" (or source2 in draft). Unicast request

Multicast flows just go through NATs anyway. But, an SDP example would be useful in your draft.

> from a receiver to Distribution source naturally open NAT for the response. It provide information on
> the RTP destination address and ssrc in RTCP FB messages (see rfc 4585) is enough to link to the right
> multicast video session.

However, it seems that your draft is not addressing the security concerns that were raised during RAMS wglc. In particular, if a client spoofs somebody else's IP, he might just start a high-bitrate unicast burst towards that client. The Cookie proposal handles this problem. 

In the last IETF, we had a breakout session to discuss these issues and in the mean time Tom V. from ALU made a different proposal (He also presented it in the WG session). Your current proposal is somewhat similar to it. In the mean time, we came together with Tom, had a few conference calls and modified the proposal such that it would address the security concerns.

We are expecting that a draft explaining this approach will be available shortly.

Cheers, acbegen.
 
> 	Secondly, the archictecture you're recommending isn't clear to me.  Are you proposing that both
> the original streaming source, and the RAMS retransmission source, share the same (presumably
> multicast) RTP session?  This seems like it would be pretty straightforward to do, though the scaling
> characteristics could be problematic.
> 
> 	Or do you intend that the original (multicast) RTP session and the retransmission (unicast?) RTP
> session are distinct, but somehow share their transport addresses to simplify NAT traversal?  I don't
> see how that's possible -- unicast and multicast have inherently different IP addresses, of course.
> 
> 
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 7 Jul 2010 15:05:45 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ali C. Begen (abegen)
> Sent: Wednesday, July 07, 2010 8:11 AM
> To: [email-masked]; Jonathan Lennox
> But you realize that we cannot actually control what the incoming
> multicast sources will use for their SSRCs, right? This was extensively
> discussed during the RAMS draft. Initially, the RAMS draft also
> mandated the use of 5576 but now we removed it since in practice it may
> not work as expected.

Specifically, it is impossible to coordinate unique SSRCs amongst all of the
various RTP senders that exist today (senders owned/controlled by the
network owner) and might exist in the future (senders owned/controlled by
external entities, e.g., FIFA for sending world cup, IOC for sending
Olympics, etc.).

-d

> ranges values. In our idea, ssrc-
> However, it seems that your draft is not addressing the security
> concerns that were raised during RAMS wglc. In particular, if a client
> spoofs somebody else's IP, he might just start a high-bitrate unicast
> burst towards that client. The Cookie proposal handles this problem.
> 
> In the last IETF, we had a breakout session to discuss these issues and
> in the mean time Tom V. from ALU made a different proposal (He also
> presented it in the WG session). Your current proposal is somewhat
> similar to it. In the mean time, we came together with Tom, had a few
> conference calls and modified the proposal such that it would address
> the security concerns.
> 
> > 	First of all, are you familiar with RFC 5576?  It allows explicit
> signaling of SSRC values in
> > SDP.
> >
> > multicast) RTP session?  This seems like it would be pretty
> straightforward to do, though the scaling
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Thu, 8 Jul 2010 16:57:43 +0200

1) A common response for both for Ali C. Begen and Dan Wing 
	Actually a world wide system cannot manage all SSRC from all SSM sources. Refering to rfc5760, there is a priority in SSCR collision that gives precedence to the Media Source (§6.5), and Media Source wait some time before changing its own SSRC (if collision with another Media source) and this delay may disturb additional services as RET or FCC. Somewhere else, is it possible for a Media Source to detect collisions with another Media Source? So SSRC from Media Source ought to never change. This only write the problem.

	Considering, in my mind, it is not realistic to envisage a Distribution Source with "nearly infinite ressources" that manage all the multicast streams. This means DS ought to receive all multicast streams to store a few seconds of each. So as many Distribution Sources (DS) must be considered, associating DS to a Media Sender guarantee SSRC consistency inside a group of multicast streams owned by a single sender (FIFA for example). As the SDP describing a stream must hold IP address and port of the FT (inside DS) and SSRC, this define a single association between a stream and a SSRC. SSRC consistency in a multicast group join to a DS is enought to efficient running.

	Resolving association between a DS and Media Senders exist also with session multiplexing.

2) Restricted cone NAT is a first protection level for security, because spoofing pkts are not allowed to go in LAN.

3) Our main idea is to have an alternative to session-multiplexing, because we believe that choosing between two solutions depend on services goals and networks properties. 

Regards,

Gerard BABONNEAU

-----Message d'origine-----
De : Ali C. Begen (abegen) [mailto:[email-masked]] 
Envoyé : mercredi 7 juillet 2010 17:11
À : BABONNEAU Gerard RD-MAPS-REN; Jonathan Lennox
Cc : [email-masked]; [email-masked]
Objet : RE: [AVT] Questions aboutdraft-babonneau-avt-ssrc-mux-for-port-mapping

> gerard.babonneau@orange- ftgroup.com
> Cc: [email-masked]; 
> [email-masked]
> Subject: Re: [AVT] Questions 
> aboutdraft-babonneau-avt-ssrc-mux-for-port-mapping
> 
> Hi,
> 

 
> Secondly, each multicast session must always be independant, notably 
> to never introduce over-rate when multiplexing in the same IP multicast address, and because the size of a multicast group may be huge.

Sure, nobody says ow.

> This is critical for DSL lines. Using independant RTCP ports for 
> multicast and unicast RTP sessions needs to link sessions together at the application layer.

Yup.
 
> ranges values. In our idea, ssrc- multiplexing is a powerfull solution 
> that use a single unicast UDP port/address to multiplex all the RTP/RTCP companion streams related to a RTP multicast one. Incoming multicast with NAT has solutions.

> from a receiver to Distribution source naturally open NAT for the 
> response. It provide information on the RTP destination address and 
> ssrc in RTCP FB messages (see rfc 4585) is enough to link to the right multicast video session.

Cheers, acbegen.
 
> signaling of SSRC values in SDP.
> 
> 	Secondly, the archictecture you're recommending isn't clear to me.  
> Are you proposing that both the original streaming source, and the 
> RAMS retransmission source, share the same (presumably
> straightforward to do, though the scaling characteristics could be problematic.
> 
> 	Or do you intend that the original (multicast) RTP session and the 
> retransmission (unicast?) RTP session are distinct, but somehow share 
> their transport addresses to simplify NAT traversal?  I don't see how that's possible -- unicast and multicast have inherently different IP addresses, of course.
> 
> 
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 8 Jul 2010 09:01:03 -0700

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, July 08, 2010 7:58 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [AVT] Questions aboutdraft-babonneau-avt-ssrc-mux-for-
> port-mapping
> 
> 	Actually a world wide system cannot manage all SSRC from all SSM
> sources. Refering to rfc5760, there is a priority in SSCR collision
> that gives precedence to the Media Source (§6.5), and Media Source wait
> some time before changing its own SSRC (if collision with another Media
> source) and this delay may disturb additional services as RET or FCC.
> Somewhere else, is it possible for a Media Source to detect collisions
> with another Media Source? So SSRC from Media Source ought to never
> change. This only write the problem.
> 
> 	Considering, in my mind, it is not realistic to envisage a
> Distribution Source with "nearly infinite ressources" that manage all
> the multicast streams. This means DS ought to receive all multicast
> streams to store a few seconds of each. So as many Distribution Sources
> (DS) must be considered, associating DS to a Media Sender guarantee
> SSRC consistency inside a group of multicast streams owned by a single
> sender (FIFA for example). As the SDP describing a stream must hold IP
> address and port of the FT (inside DS) and SSRC, this define a single
> association between a stream and a SSRC. SSRC consistency in a
> multicast group join to a DS is enought to efficient running.

If I understand the above correctly, you're saying:

  * a media sender will ensure unique SSRCs for the channels they are 
    sending.  An example of a media sender might be FIFA sending out
    10s or 100s of camera angles at different resolutions/quality.
  * And, where multiple senders are involved, they will not ensure 
    SSRC uniqueness between themselves.  And in that case a different
    feedback port is used.

Is that an accurate summary?

> 2) Restricted cone NAT is a first protection level for security,
> because spoofing pkts are not allowed to go in LAN.

I do not understand the relevance of that statement.  The attack
described by Ali is an attacker, somewhere on the network, spoofing
a victim's source IP address to a retransmission server and causing
the retransmission server to send a burst of data to the victim.
This is a (significant) packet amplification attack.  Dropping
the attack packets at the NAT is somewhat interesting, however the
problem is flooding the subscriber's access link with the burst
traffic from the retransmission server.

> 3) Our main idea is to have an alternative to session-multiplexing,
> because we believe that choosing between two solutions depend on
> services goals and networks properties.

The advantages of the approach described in 
draft-babonneau-avt-ssrc-mux-for-port-mapping can be also be
achieved with session multiplexing.  We hope to publish our
Token-based approach shortly which will show how to achieve
similar benefits and similar simplicity.

-d

> > to never introduce over-rate when multiplexing in the same IP
> multicast address, and because the size of a multicast group may be
> huge.
> 
> Sure, nobody says ow.
> 
> > their transport addresses to simplify NAT traversal?  I don't see how
> that's possible -- unicast and multicast have inherently different IP
> addresses, of course.
> >
> >
> >
> >