Subject: [AVT] a comment about SRTP & NATs

From: [email-masked]
Date: Fri, 7 Jun 2002 14:09:27 +0200

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jun 2002 10:38:33 -0400

inline.

> But this is not absolutely clear  in case of NAT(s) en route.

I could be wrong (not being intimately familiar with SRTP), but it is my 
understanding that the context ID is never placed into the message or 
used as an input to any hash or encryption algorithms; its merely an 
index at the sender and receive to retrieve the context. If that is the 
case, it really doesn't matter that the sender and receiver have 
different values for the context ID because of nat, so long as the 
values don't change during the session, and that they have a 1-1 
relationship.

As an example, if A sends to B, and A sends to 10.0.1.1:8864, and when B 
receives it, the destination address:port is 1.2.3.4:6554, A will use 
10.0.1.1:8864 for the context ID, and B uses 1.2.3.4:6554 for the 
context ID. So long as A always sends to 10.0.1.1:8864, and this is 
consistently received at B as 1.2.3.4:6554, things should work fine; 
both sides will consistently retrieve the appropriate cryptographic context.

-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: Fri, 07 Jun 2002 07:51:21 -0700

Jonathan,

At 10:38 AM 6/7/2002 -0400, Jonathan Rosenberg wrote:
>understanding that the context ID is never placed into the message or used 
>as an input to any hash or

The triple that identifies the context comes from the RTP packet.
The SSRC is used in the initialization vector for the two AES modes,
CM and f8.

Mark

>encryption algorithms; its merely an index at the sender and receive to 
>retrieve the context. If that is the case, it really doesn't matter that 
>the sender and receiver have different values for the context ID because 
>of nat, so long as the values don't change during the session, and that 
>they have a 1-1 relationship.
>
>10.0.1.1:8864 for the context ID, and B uses 1.2.3.4:6554 for the context 
>ID. So long as A always sends to 10.0.1.1:8864, and this is consistently 
>received at B as 1.2.3.4:6554, things should work fine; both sides will 
>consistently retrieve the appropriate cryptographic context.
>
>-Jonathan R.
>
>
>--

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jun 2002 11:02:07 -0400

Mark Baugher wrote:
>>>   where the destination network address and the destination
>>
> transport
> 
>>>   port are the ones in the current RTP packet (for the sender) or
>>
> SRTP
> 
>>I could be wrong (not being intimately familiar with SRTP), but it is
> 
> my 
> 
> used 

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.

-Jonathan R.

---

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

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

>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