Subject: RE: AW: [AVT] More on SRTP and SPI.

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 27 Aug 2001 07:53:47 -0700

Hi Colin,

> 
> --> Euchner Martin writes:
> >Yes, there should be some easy parseable signaling means for the
> >recipient(s) to determine whether SPI is present or not. I 
> would pretty
> >much prefer this some bit in the RTP header, e.g.  M Bit or 
> X bit and some
> >SPI extension flag or perhaps with V = 3
> >
> 
> Why not signal it in the call setup? There's no need to put this
> information into the packets.
> 

Well for starters, it makes things significantly more complicated: you must
first match the media stream to the session entity, which is not a trivial
task (or always possible immediately) before you can decode or authenticate
the packet. [not a good design IMO]

I complete agree that the length of all the other fields should be obtained
from the session information but since the SPI value can be useful
identifying that session information I think it should be independently
parseable/determinable.

Secondly, in the example I gave where a media stream transitions from not
using SPI to using SPI (because it needs a new context) then this would not
be possible to achieve this robustly & seamlessly [the same media sender can
have multiple contexts]. You should not be _forced_ to change the SSRC or
media address just because you need a new cryptographic context (IMO).

To reproduce my suggestion:

We could use first three bits of each optional field determine tag type:

So 1 byte SPI could be 001 + 5bit SPI value 
So 2 byte SPI could be 010 + 13bit SPI value
So 3 byte SPI could be 011 + 21bit SPI value
So 4 byte SPI could be 100 + 29bit SPI value
Authentication tag starts with 101 + 5 spare signaling bits + remainder of
authentication tag

This also saves bandwidth when using SPI which is a benefit (and as it says
in the draft, SPI is the only robust method). SPI values are not like SSRC
values that need a degree of randomness to prevent collision, etc. The
smaller SPI values can be _normally_ used.

Robert.

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 28 Aug 2001 14:11:47 -0400

Okay, so can we make the SPI mandatory? That might make things easier to
manage...

Colin

---

From: Mark Baugher <[email-masked]>
Date: Tue, 28 Aug 2001 13:22:51 -0700

Colin,
    I think there should be an SPI option in SRTP so that <SPI, SSRC, Dest 
transport address> can be used in place of <SSRC, Dest transport address> 
to identify the crypto context.  An implementation that supports SPIs, and 
we don't want this to be a MUST, will run a key management protocol that 
initializes an SPI-present attribute in the crypto context.  A so-configure 
SRTP will use the SPI field from the RTP packet when <SSRC, Dest transport 
address> references an RTP session that has one or more crypto contexts 
with SPI-present set.  I think that the SPI should be optional and not 
mandatory.  I don't think it solves any other problems outside of allowing 
two cypto contexts to be in place for an RTP session; the idea is that 
there is a "current" crypto context and a "future" crypto context - we'll 
switch to the latter when the SPI value references it.  Many applications 
don't need this function and should not be forced to implement it, in my 
opinion.

Mark

---

From: Mats Näslund <[email-masked]>
Date: Wed, 29 Aug 2001 09:08:03 +0200

> Okay, so can we make the SPI mandatory? That might make things easier to

Unfortunately not. I agree with Mark and Robert, and I belive it 
would be unacceptable from our perspective.

Best,

/Mats

---

From: Colin Perkins <[email-masked]>
Date: Wed, 29 Aug 2001 08:38:11 -0400

>would be unacceptable from our perspective.

Okay :) 

Colin