Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-rejected-05
"A. Jean Mahoney" <mahoney@nostrum.com> Mon, 08 April 2019 22:17 UTC
Return-Path: <mahoney@nostrum.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9BF120684 for <sipcore@ietfa.amsl.com>; Mon, 8 Apr 2019 15:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QoTDKEPtIE1U for <sipcore@ietfa.amsl.com>; Mon, 8 Apr 2019 15:17:56 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2345D120687 for <sipcore@ietf.org>; Mon, 8 Apr 2019 15:17:56 -0700 (PDT)
Received: from mutabilis-2.local ([47.186.39.7]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x38MHsm4096158 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 8 Apr 2019 17:17:55 -0500 (CDT) (envelope-from mahoney@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554761875; bh=IcXidcUp/zpwp4HV5jyR+vsao/k76grTFo4UXqmbjYs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=PIcRNIHyGJnerKV6EIWpzEzNmiJwsAyf3yahwxciFVXPx1piUGKn43uYlir/WJvGD 9BXEbnbQbAed3Sa5mlsjIq5mdbiv9N23W5J273kkMnfXkfW4TQJjsmvCyn1/z7p+Js 4UXEauRcOwpPTff18Q/Dq4TaqM5Dde5KX3uZUhuQ=
X-Authentication-Warning: raven.nostrum.com: Host [47.186.39.7] claimed to be mutabilis-2.local
To: Eric Burger <eburger@standardstrack.com>
Cc: SIPCORE <sipcore@ietf.org>
References: <2508d59d-e270-cfa4-e79c-d9da0f3c589c@nostrum.com> <F08720C2-2DB7-4F45-BF5C-E253D5B84619@standardstrack.com>
From: "A. Jean Mahoney" <mahoney@nostrum.com>
Message-ID: <258a1ac5-579b-7078-ab78-8a7c375e205a@nostrum.com>
Date: Mon, 08 Apr 2019 17:17:54 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <F08720C2-2DB7-4F45-BF5C-E253D5B84619@standardstrack.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/j11abwOe5NzEOO_vbOSaBXcNUcA>
Subject: Re: [sipcore] Doc Shepherd review of draft-ietf-sipcore-rejected-05
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2019 22:18:07 -0000
Hi Eric, Thanks given ;-) I've completed the Document Shepherd write-up: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/shepherdwriteup/ And have requested publication. Next step will be for the AD to review. Jean On 4/7/19 2:35 PM, Eric Burger wrote: > Updates have been done. I could not tell you who did the updates because now it has been passivized ;-) > > The only update not applied is that while it is best to protect the key, it really needs to be protected at rest. > > >> On Apr 2, 2019, at 5:39 PM, A. Jean Mahoney <mahoney@nostrum.com> wrote: >> >> Hi Eric and Bhavik, >> >> Thanks for addressing all of the feedback so far. In preparation for the Doc Shepherd Write-up, I have run idnits, gone through the ID Checklist, and made my own pass through the draft. I have the following feedback below (overwhelmingly nits) - >> >> Thanks! >> >> Jean >> >> >> ------------------------------------------------------------------------ >> Major issues: >> ------------- >> >> None. >> >> >> Minor issues: >> ------------- >> >> The Terminology section still needs a bit of tweaking (idnits complains): >> >> In draft: >> >> This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", >> "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and >> "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only >> when, they appear in all capitals, as shown here. >> >> >> Current boilerplate: >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and >> "OPTIONAL" in this document are to be interpreted as described in >> BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all >> capitals, as shown here. >> >> >> Nits: >> ----- >> >> Throughout the document, replace "Call-Info header" with "Call-Info header field". >> >> >> 1. Introduction >> >> Expand the acronym UAC on first use. >> >> s/Figure 1 and Figure 2 shows/Figure 1 and Figure 2 show >> >> >> Current: >> >> The problem here is that network elements downstream >> from the intermediary might interpret the 607 as a user (human) >> marking the call as unwanted, as opposed to a statistical, machine >> learning, vulnerable to the base rate fallacy [BaseRate] algorithm >> rejecting the call. In other words, those downstream entities should >> not be relying on another entity 'deciding' the call is unwanted. >> >> >> Suggested: >> >> The problem here is that network elements downstream >> from the intermediary might interpret the 607 as coming from a user >> (human) that has marked the call as unwanted, as opposed to coming >> from an algorithm using statistics or machine learning to reject >> the call. An algorithm can be vulnerable to the base rate fallacy >> [BaseRate]. In other words, those downstream entities should not rely >> on another entity 'deciding' the call is unwanted. >> >> >> s/SIP header passed back/Call-Info header field passed back >> >> >> >> 3.3 UAC Operation >> >> s/feature capability tag in the INVITE request/feature capability indicator in the Feature-Caps header field of the INVITE request >> >> >> >> 3.4 Legacy Interoperation >> >> Current: >> >> One aspect of using a feature capability is only the network elements >> that will consume (UAC) or play an announcement (media gateway, SBC, >> or proxy) need understand the sip.608 feature capability. All other >> (existing) infrastructure can remain without modification, assuming >> they are conformant to Section 16.6 of [RFC3261], specifically they >> will pass headers such as "Feature-Capability: sip.608" unmodified. >> >> Suggested: >> >> One aspect of using a feature capability is that only the network >> elements that will either consume (UAC) or play an announcement >> (media gateway, session border controller (SBC) [RFC7092], or proxy) >> need to understand the sip.608 feature capability. The rest of the >> infrastructure does not need to be modified, assuming that the other >> network elements conform to Section 16.6 of [RFC3261], specifically >> that they will pass header fields such as "Feature-Capability: >> sip.608" unmodified. >> >> >> >> 3.5 Announcement Requirements >> >> s/that will be doing the announcement/that handles the announcement >> >> s/the modality for conveying/how to convey >> >> >> >> 4.1 Full Exchange >> >> In the examples, follow guidance from RFC2606, RFC3849, and RFC6890 on constructing example addresses, FQDNs, and TNs: >> o Replace IPv4 addresses with addresses in the example space >> [RFC6890]: 192.0.2.0/24 >> Or better yet, use IPv6 examples [RFC3849]: 2001:DB8::/32 >> o Use example FQDNs specified in [RFC2606]. >> o Use example phone numbers in the following space: >> +1<area code>555<0100-0199> >> >> >> s/exemplary purposes/example purposes >> >> s/at rest/at best >> >> >> >> 5.4. Call-Info Purpose >> >> Current: >> >> This >> modifies the registry header field parameters and parameter values by >> adding this RFC as a reference to the line for the header field >> "Call-Info" and parameter name "purpose": >> >> Suggested: >> >> This >> modifies the "Header Field Parameters and Parameter Values" >> subregistry of the "Session Initiation Protocol (SIP) Parameters" >> registry by adding this RFC as a reference to the line for the >> header field "Call-Info" and parameter name "purpose": >> >> >> >> 6. Security Considerations >> >> Current: >> >> Another risk is for an attacker to purposely not include the sip.608 >> feature capability in a flood of INVITE requests, direct those >> requests to proxies known to insert the sip.608 feature, and direct >> the SDP to a victim device. >> >> Suggested: >> >> Another risk is for an attacker to flood a proxy that supports the >> sip.608 feature with INVITE requests that lack the sip.608 feature >> capability in order to direct the SDP to a victim's device. >> >> s/pharming/phishing (For more info on this edit, see RFC4949) >> >> s/lookup/look up >> >> s/dialled/dialed >> >> s/jourisdiction's/jurisdiction's >> >> >> >> 8.3 Informative References >> >> [BaseRate] s/ http://www.dtic.mil/get-tr-doc/pdf?AD=ADA045772 / >> https://apps.dtic.mil/docs/citations/ADA045772 >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >
- [sipcore] Doc Shepherd review of draft-ietf-sipco… A. Jean Mahoney
- Re: [sipcore] Doc Shepherd review of draft-ietf-s… Eric Burger
- Re: [sipcore] Doc Shepherd review of draft-ietf-s… A. Jean Mahoney