RE: draft-wing-sipping-srtp-key-00.txt

["Dan Wing" <dwing@xxxxxxxxx>]

> Thanks for putting forward an interesting draft.  I'm still 
> thinking it through but in the meantime I have a couple of 
> questions related to the text of what you wrote. 
> 
> 1. In Figure 1 in section 3.2 you show two lines of "rcrypto" 
> and it's not clear to me why.  If I understand the idea 
> correctly, in a "normal" voice conversation between two 
> phones would there not be one "crypto" line and ONE "rcrypto" 
> line?    Is the example in Figure 1 just to show that there 
> *could* be multiple rcrypto lines?  (If that's the case, for 
> the sake of clarity can I suggest that the first example only 
> have the "regular" number of lines.) 

Yes, that's why we did that.  We'll show a simplier case in the
next version of the document, and also show this case.

> 2. I notice the extension of crypto with "SSRC".  How is it 
> to be delimited within the crypto value?  Is it just on its 
> own line? 

It's an extension of the a=crypto line itself.  Due to formatting
constraints, it's difficult to show the line continuation.  In
the next version, we will use a backslash character to make it
more obvious that it's one long SDP line, and we will also have
a real grammar section.

> I have not worked enough with the parsing of the 
> crypto line to know how SIP implementations handle it, but 
> purely reading the spec, seeing a separate line and an 
> additional "=" sign would make me curious how this would be parsed. 
> 
> 3. In Section 7, "Examples", none of the examples contain the 
> SSRC line.  Was this intentional or just an oversight? 

That's a mistake.  Thank you for pointing it out.

> 4. I think it would be helpful to include in the draft an 
> example or narrative description from a slightly higher level 
> view of where this PUBLISH message fits into the overall SIP 
> call flow.

Alright.

> In order to have both keys, it obviously has to 
> occur after the SIP INVITEs, etc. where the call has been 
> established... yet also needs to occur before the audio 
> really starts streaming.  (Or does it?  Is there a race 
> condition here?) 

It doesn't necessarily need to occur before the audio starts
flowing.  I mean, for example, consider sdescriptions -- the
answerer could start sending SRTP immediately, before its
SDP answer has been received.  Similarly, several MIKEY
modes have this same weakness (-RSA-R, -DHSIGN, and others).

With forking it gets worse; the easy answer is to wait until
one of the forked endpoints answers (200) and only bother
to send the PUBLISH at that point.  This gets even worse 
if you are receiving early SRTP media from one or more of
the forked endpoints.

> I'm not saying you have to rehash the whole 
> of RFC 3903, but a quick summary of the process and/or 
> another example showing the high-level packet flow would be 
> very helpful to those seeking to understand the proposal. 

I agree that would be helpful.

> As I said, I'm still thinking through the implications of the 
> proposal, but thought I throw out these more 
> formatting-related questions in the meantime. 

Thanks,
-d


> My 2 cents, 
> Dan 
> 
> -- 
> Dan York, CISSP
> Dir of IP Technology, Office of the CTO
> Mitel       http://www.mitel.com
> dan_york@xxxxxxxxx +1-613-592-2122
> PGP key (F7E3C3B4) available for 
> secure communication
> 
> 
>