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

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, July 08, 2010 7:58 AM
> To: [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]; draft-babonneau-avt-ssrc-mux-for-port-
> [e-mail]
> Subject: RE: [AVT] Questions aboutdraft-babonneau-avt-ssrc-mux-for-
> port-mapping
> 
> 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.

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?

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

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


> Regards,
> 
> Gerard BABONNEAU
> 
> 
> 
> -----Message d'origine-----
> De : Ali C. Begen (abegen) [mailto:[e-mail]]
> Envoyé : mercredi 7 juillet 2010 17:11
> À : BABONNEAU Gerard RD-MAPS-REN; Jonathan Lennox
> Cc : [e-mail]; draft-babonneau-avt-ssrc-mux-for-port-
> [e-mail]
> Objet : RE: [AVT] Questions aboutdraft-babonneau-avt-ssrc-mux-for-port-
> mapping
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of
> > gerard.babonneau@orange- ftgroup.com
> > Sent: Wednesday, July 07, 2010 9:21 AM
> > To: Jonathan Lennox
> > Cc: [e-mail];
> > [e-mail]
> > 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.
> 
> > Regards,
> >
> > Gérard BABONNEAU
> >
> > Jonathan Lennox a écrit :
> >
> > 	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.
> >
> >
> >
> >