I just submitted a version -03 of media-security-requirements,
http://www.ietf.org/internet-drafts/draft-ietf-sip-media-security-requirements
-03.txt


The major changes to the document include:

* After the discussion on the mailing list about R-REUSE, I have returned that
requirement to a MAY.


* Offline, Peter Schneider sent a detailed review of
draft-ietf-sip-media-security requirements.  Many of his comments were
resolved with new text or editorial changes, but a few of his comments
resulted in new or adjusted requirements.  He also had comments about R-REUSE
and suggested it should not be a MUST-level requirement.


* I added a new requirement, R-HERFP; there was existing discussion text
around handling HERFP correctly, but this creates a specific requirement:

   R-HERFP:
         The media security key management protocol MUST function
         securely even in the presence of HERFP behavior.


* To the discussion of the R-PSTN requirement, (which is unchanged and 
says "The media security key management protocol MUST support termination 
of media security in a PSTN gateway."), I added:

     It is desirable, even when one leg of a call is on the 
     PSTN, that the IP leg of the call be protected with SRTP.

This comment has some relationship with the active discussion (and I-D's) we
are have with RFC4474 and E.164 numbers, so this may need revision.  What I'm
trying to do is ensure we have SRTP on the IP leg, even if we know (or
suspect) the call is going across the PSTN.  There is no need to force RTP
over the IP leg of a call just because the call is going over the PSTN later.


* As mentioned above, R-REUSE has been returned to a MAY (it was only a MUST
in version -02 of the document):

   R-REUSE:
         The media security key management protocol MAY support the re-
         use of a previously established security context.

               Note: re-use of the security context does not imply 
               re-use of RTP parameters (e.g., payload type or SSRC).


* The R-AVOID-CLIPPING requirement now references Security Preconditions
rather than simply PRACK.


* Other changes can be seen by running rfcdiff,
http://www.tools.ietf.org/rfcdiff

-d



_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

Reply via email to