Subject: Re: [AVT] a comment about SRTP & NATs

From: Mark Baugher <[email-masked]>
Date: Fri, 07 Jun 2002 06:39:37 -0700

hi Phillipe
   We don't deal with mixers and translators in
http://www.ietf.org/internet-drafts/draft-ietf-avt-srtp-04.txt
except to say that they break end-to-end security
(viz. section 7.4).  Note that
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-11.txt
identify firewalls as a problem for RTP-level translators/mixers.
I think we should defer work on SRTP intermediate systems until
we have more experience with SRTP and until the firewall traversal
protocols are mature.  We'd be wrong IMHO to reference STUN in
a protocol (SRTP) that's being considered as a Proposed
Standard when STUN is not yet a Proposed Standard.

Mark

At 02:09 PM 6/7/2002 +0200, [email-masked] wrote:

>The SRTP specs (draft-ietf-avt-srtp-04.txt) says (section 3.1.3)
>
>"
>A cryptographic context SHALL be uniquely identified by the triplet
>    context identifier:
>
>    context id = <SSRC, destination network address, destination
>    transport port number>
>
>    where the destination network address and the destination transport
>    port are the ones in the current RTP packet (for the sender) or SRTP
>    packet (for the receiver). It is assumed that, when presented with
>    this information, the key management returns a context with the
>    information as described in Section 3.1.
>"
>
>But this is not absolutely clear  in case of NAT(s) en route.
>
>I think it would be better to say that the SRTP cryptographic context is 
>SSRC and
>  destination address/port *as sent from the sender*
>
>(since it can be changed en route by  NATs)
>
>one then has to  assume that the receiver is aware of *this*
>"sender-side" address/port (via STUN for example)
>since it is a sine-qua-non condition for RTP anyway
>and then the receiver can use this info with the key management
>to retreive the correct context.
>
>Regards,
>
>Philippe Gentric
>Software Architect
>Philips MP4Net
>[email-masked]
>http://www.mpeg-4.philips.com
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt

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

---

From: [email-masked]
Date: Fri, 7 Jun 2002 19:18:43 +0200

OK,

That it will work I was suspecting, I am fully satisfied now.

I also agree it does not need to reference STUN,
nor any detailed consideration on FW/NAT traversal;
still:
 is not the sentence weirdly formulated ?

again:

<quote>
"A cryptographic context SHALL be uniquely identified by the triplet context identifier:
context id = <SSRC, destination network address, destination transport port number>
where the destination network address and the destination
transport port are the ones in the current RTP packet (for the sender)"
</quote>

Not only does it *not* say that the client and the server may need to maintain a *different* one
(triplet) *and* identify that they correspond to each other
but it says "uniquely" at a distance of approximately 4 ASCII characters from a
RFC2119 capitalized key word ...

so IMHO the sentence is either too elusive or too precise !
(or is it my english playing tricks on me again ;?)

...

Unless of course you accept the idea that you would end up with the need
to later redefine that "uniquely" -in the context of SRTP-
actually signifies that every IP device on the planet has its own ?-)

regards,

Philippe Gentric
Software Architect
Philips MP4Net

                      Mark Baugher                                                                                                     
                      <mbaugher@cisco.             To:  Jonathan Rosenberg <[email-masked]>                                   
                      com>                         cc:  Philippe Gentric/MP4-SUR/CE/PHILIPS@EMEA1                                      
                                                    [email-masked]                                                                       
                      07/06/2002 17:39             Subject:   Re: [AVT] a comment about  SRTP & NATs                                   
                                                                                                                                       
                                                   Classification:                                                                     

At 11:02 AM 6/7/2002 -0400, Jonathan Rosenberg wrote:

>Yes. Let me be more clear. The destination address and port are not
>present in the packet anywhere else but in the destination address and
>port fields (for example, within the body of the RTP packet or something).
>If the addresses were placed elsehwere, or used as inputs to a hash, we
>would have problems. However, it does not seem to be the case.

You're right.  SRTP does not put addresses in RTP packets
and does not use IP addresses nor ports in its message
authentication hash.

Mark

>-Jonathan R.
>
>
>
>--
>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
>Chief Scientist                         First Floor
>dynamicsoft                             East Hanover, NJ 07936
>[email-masked]                 FAX: (973) 952-5050
>http://www.jdrosen.net                  PH:  (973) 952-5000
>http://www.dynamicsoft.com
>
>

---

From: Mark Baugher <[email-masked]>
Date: Tue, 11 Jun 2002 16:18:31 -0700

Phillipe,
   Pardon my delay in responding.

>That it will work I was suspecting, I am fully satisfied now.

Good.

>transport port are the ones in the current RTP packet (for the sender)"

I think this can be a problem for key management
not for SRTP.

>RFC2119 capitalized key word ...

"unique" is the offending word?

>(or is it my english playing tricks on me again ;?)

I don't see the problem with the SRTP definition.  Here is
the rtp-new definition of a session:
"
RTP session: The association among a set of participants communicating with 
RTP. For each participant, the session is defined by a particular pair of 
destination transport addresses (one network address plus a port pair for 
RTP and RTCP). The destination transport address pair may be common for all 
participants, as in the case of IP multicast, or may be different for each, 
as in the case of individual unicast network addresses and port pairs. In a 
multimedia session, each medium is carried in a separate RTP session with 
its own RTCP packets. The multiple RTP sessions are distinguished by 
different port number pairs and/or different multicast addresses.
"
An SRTP session is an RTP session with an SSRC.

thanks, Mark

> Baugher