Re: [stir] AD Review: draft-ietf-stir-oob

["Peterson, Jon" <[e-mail]>]

Hey Adam,

The new version of -oob hopefully contains all of the fixes you recommended below. Thanks for those!

It also incorporates a bit of new language in the section about substitution attacks, which has come under increasing scrutiny in the industry these past months. Largely, it just enumerates some potential countermeasures and gives more detail on the attack itself.

I also added a little to the section on CPS discovery in response to other comments I've received.

With that, I hope this is in pretty good shape.

Thanks again,

Jon Peterson
Neustar, Inc.

On 9/2/19, 10:18 PM, "Adam Roach" <[e-mail]> wrote:

    This is my AD review for draft-ietf-stir-oob. I will be requesting
    that it be put in IETF last call shortly.
    
    Thanks to everyone involved for taking the work to work out and document the
    thinking so far on an out-of-band mechanism. I have no substantive comments,
    and only a small number of editorial suggestions, below. Please treat 
    these as
    any other IETF last call comments.
    
    /a
    
    
    ---------------------------------------------------------------------------
    
    §1:
    
     >  do use SIP do not always carry SIP signaling end-to-end. Xalls from
    
    Nit: "Calls"
    
    ---------------------------------------------------------------------------
    
    §1:
    
     >  This specification therefore builds on the PASSporT [RFC8225]
     >  mechanism and the work of [RFC8224] to define a way that a PASSporT
     >  object created in the originating network of a call can reach the
     >  terminating network even when it cannot be carried end-to-end in-band
     >  in the call signaling.  This relies on a new service defined in this
     >  document called a Call Placement Service (CPS) that permits the
     >  PASSporT object to be stored during call processing and retrieved for
     >  verification purposes.
    
    This is still phrased as if the remainder of this document is a complete
    specification of mechanism rather than the more limited scope described
    in the paragraph that follows it. Perhaps:
    
    s/This specification/The techniques described in this document/
    s/define a way/describe a way/
    
    ---------------------------------------------------------------------------
    
    §5.2:
    
     >  A call originates with an enterprise PBX that has both Internet
     >  access and a built-in gateway to the PSTN, which communicates through
     >  traditional telephone signaling protocols.  The PBX immediately drops
     >  the call to the PSTN
    
    The colloquial use of "drops" in this context can be confusing. (I had to
    re-read to ensure that it meant "routes" rather than "aborts"). Perhaps
    "...immediately routes the call..."
    
    The same comment applies to §5.3.
    
    ---------------------------------------------------------------------------
    
    §5.3:
    
     >  If
     >  so, it can retrieve the PASSporT and, when it creates a SIP INVITE
     >  for this call, add a corresponding Identity header per [RFC8224].
    
    Nit: "...Identity header field..."
    
    ---------------------------------------------------------------------------
    
    §5.5:
    
     >  the SIP call with an Identity header.  As a fallback in case the call
    
    Nit: "...Identity header field."
    
    ---------------------------------------------------------------------------
    
    §6.2:
    
     >  This requires the retargeting entity to generated
     >  encrypted PASSporTs that show a secure chain of diversion:
    
    Nit: "...to generate..."
    
    ---------------------------------------------------------------------------
    
    §8.1:
    
     >  or more credentials that can be used to sign for that identity, be it
     >  a domain or a telephone number or something other identifier.  For
    
    Nit: "...or some other identifier."
    
     >  Identity header field value of the SIP request - though SIP would
     >  carry cleartext version rather than an encrypted version sent to the
    
    Nit: "...carry a cleartext..."
    
    ---------------------------------------------------------------------------
    
    §8.3:
    
     >  could receive a call with an Identity header, extract a PASSporT from
     >  the Identity header, and store that PASSporT at a CPS.
    
    Nit: "...Identity header field..." (twice)
    
    ---------------------------------------------------------------------------
    
    §9:
    
     >  As an rough example, we show a Call Placement Service implementation
    
    Nit: "...a rough..."
    
    ---------------------------------------------------------------------------
    
    §10:
    
     >  This document does not prescribe any single way to do service
     >  discovery for a CPS; it is envisioned that initial deployments will
     >  provision the location of the CPS at the AS and VS.
    
    Nit: expand the acronyms "AS" and "VS".