Requirements for End-to-Middle Security for the Session Initiation Protocol (SIP)
draft-ietf-sipping-e2m-sec-reqs-06

Reviewed by Suzanne Woolf, Gen-ART

Her review:

This document seems to be in pretty good shape to be published as
Informational; it motivates the need for e2m and describes the
characteristics of successful e2m security for SIP.

However, I have some reservations. I may have found it hard to follow
simply because I know little about the underlying protocol. But it may
need to be clarified in several places, e.g. "This requirement is not
necessary when a provider that operates the proxy server does not
permit to reveal the security policies to a different provider that
the recipient UA belongs to." I *think* I know what it means but it
might be clearer to say "This requirement is not necessary when the
provider operating the proxy service does not allow its security
policies to be revealed to the provider serving the recipient UA."

  Section 2.1: s/request base on/request based on/

  Section 2.1: ASCII Art is difficult, and often subjective.  To me,
  the following is more self-consistent.  In the original, I was asking
  myself if the inconsistencies meant anything, and I convinced myself
  that they did not.  Second, I propose "[C]" to denote a content that
  is protected.  This allows multiple layers of encapsulation to be
  shown if needed.

                    Home Network
              /---------------------\
              | +-----+     +-----+ |   +-----+     +-----+
    User #1-----|  C  |-----| [C] |-----| [C] |-----|  C  |-----User #2
              | +-----+     +-----+ |   +-----+     +-----+
              | UA #1      Proxy #1 |   Proxy #2     UA #2
              \---------------------/
  
  If you accept any of these changes, please consistently use them in the
  rest of the figures too.

  Section 2.2.1: The 2nd paragraph of this section should read:
  >
  > This service might be deployed in financial networks, health care
  > service provider's networks, as well as other networks where
  > archiving communication is required by their security policies.

  Section 4.1: I think the following revised text has the same meaning,
  but I think it is more straightforward:
  >
  > REQ-GEN-2: It SHOULD NOT have an impact on proxy servers that do
  >            not provide services based on S/MIME-protected bodies
  >            in terms of handling the existing SIP headers.

  Reference [4] should point to RFC 3850.

  Reference [6] should point to a specification of the Location Object,
  not the requirements for the location object.