Re: [P2PSIP] Spencer Dawkins' Yes on draft-ietf-p2psip-sip-19: (with COMMENT)

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Tue, 19 April 2016 19:42 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF4D12EA86; Tue, 19 Apr 2016 12:42:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 rV7iJ4qzLNmm; Tue, 19 Apr 2016 12:42:08 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 2850612EA39; Tue, 19 Apr 2016 12:42:08 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id j74so26329253ywg.1; Tue, 19 Apr 2016 12:42:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=s+U//AYAdD6Ls0BRo5rXEDC0Trygxf3Xdy2UN+V/UZM=; b=f34u+xAkkpKpU3bay7P/bcRORf3X9WB01FuDwlCoTs93hbugt19EDRMJDXRIWDeK91 v/TSt8ogIW/5OrhXnjG47q+P0uhtuSRdB3RzFeoslAqQyI8rg1a9jSfVBPSPoHhrtDzu c/w1aXbObVDpgV5HpEx7AFzN3jwbOzy2hDYauZpUdkyOISG8ST/4KxPxesXdUTL2sYsx reb/Or+5T+x7hGXVfPNa4mYyi49t+6qbZw2YKwOzoBBzFhMqwgA9Pgpvij3xurEOIPea C4mQSqOAmAfaGvUZ2JQQ4RBbCtcWSs3Qb05pVO5Zh4iUOLl3ifbR5/YJ21IoQ5V+oFbY rb5w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=s+U//AYAdD6Ls0BRo5rXEDC0Trygxf3Xdy2UN+V/UZM=; b=DMvYH0nBP2JhvLp10kiHNxvhQRY1ywsy/rWV+IJ/3Lk47fpfHPj53z4dFLqAazREAj BNjfd49Tq+18DoFXA7t6T97p/1jynvq0lhgW6Grlpgc6FOFmmyqyhocRJlCUic4QzPt9 TKx2/eps66aZ/ysF8Rb5N+GrSRwfbPcNQo+Q3hSTRmd6JXquhGyOPf8FkK/wZWSuXFcl PFkQxvqttYNQzQ2Iz5+Ayt190tE8jSCFUJDDwjvdpXw5rq/VbpvyJlZoIa2QnCZdMoSq Zq6EKkORyUFMafdpobUw++7gflQ+PUvFhuZfCsSr5TrEft8AR5XiFVda3vGhGA7h83ja ckcg==
X-Gm-Message-State: AOPr4FVShAL7W8REbaf2lpqtyiADBRsI5ZUcn+RieRZMF4Cx6fTJ80EYD9CbSQUm5ydZhuYfciAxbixWOpFkZw==
MIME-Version: 1.0
X-Received: by 10.129.122.66 with SMTP id v63mr2860246ywc.219.1461094927327; Tue, 19 Apr 2016 12:42:07 -0700 (PDT)
Received: by 10.37.224.212 with HTTP; Tue, 19 Apr 2016 12:42:07 -0700 (PDT)
In-Reply-To: <571687BE.4030102@haw-hamburg.de>
References: <1f2c375f331244cda4173088497a309b@HUB02.mailcluster.haw-hamburg.de> <571687BE.4030102@haw-hamburg.de>
Date: Tue, 19 Apr 2016 14:42:07 -0500
Message-ID: <CAKKJt-cgDhPZH3TDCFS7rZaFXXDZ5qZPgcQHp1UkKfH3hGXnPg@mail.gmail.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
To: "Thomas C. Schmidt" <t.schmidt@haw-hamburg.de>
Content-Type: multipart/alternative; boundary="94eb2c0b1a26206d2f0530dbac59"
Archived-At: <http://mailarchive.ietf.org/arch/msg/p2psip/9NkeoIPiKJQvdWkox6v-HLSGoGQ>
Cc: "p2psip-chairs@ietf.org" <p2psip-chairs@ietf.org>, "p2psip@ietf.org" <p2psip@ietf.org>, Spencer Dawkins <spencer.dawkins@huawei.com>, "draft-ietf-p2psip-sip@ietf.org" <draft-ietf-p2psip-sip@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [P2PSIP] Spencer Dawkins' Yes on draft-ietf-p2psip-sip-19: (with COMMENT)
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/p2psip/>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Apr 2016 19:42:10 -0000

Hi, Thomas,

On Tue, Apr 19, 2016 at 2:32 PM, Thomas C. Schmidt <t.schmidt@haw-hamburg.de
> wrote:

> Hi Spencer,
>
> many thanks for the feedback - please see inline.
>
> On 19.04.2016 16:03, Spencer Dawkins wrote:
>
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> This was a bit confusing to me.
>>
>>     AOR domain not supported by overlay?  If the domain part of the AOR
>>        is not supported in the current overlay, the user SHOULD query the
>>        DNS (or other discovery services at hand) to search for an
>>        alternative overlay that services the AOR under request.
>>        Alternatively, standard SIP procedures for contacting the callee
>>        SHOULD be used.
>>
>> If you don't query the DNS (or other discovery services), and you don't
>> use standard SIP procedures, are there any other choices? With both of
>> these being SHOULDs, a conformant implementation might not do either of
>> them. Is that expected?
>>
>> If you need this to be RFC 2119 language, I'm guessing this would be
>> "MUST either do X or Y", but I'm not sure it needs to be RFC 2119.
>>
>> If you really do need two alternative SHOULDs, it's not required to
>> explain why a SHOULD is not a MUST, but since the goal is that an
>> implementer is making an informed choice, helping the implementer
>> understand why one might not want to do what one SHOULD do is usually
>> helpful.
>>
>>
> I see - the normative SHOULDs appear indeed a bit strong. The described
> case is "you query the wrong overlay, so we give some hints on what else
> you could do".
>
> Suggested rephrase:
>
>    AOR domain not supported by overlay?  If the domain part of the AOR
>       is not supported in the current overlay, the user MAY query the
>       DNS (or other discovery services at hand) to search for an
>       alternative overlay that services the AOR under request.
>       Alternatively, standard SIP procedures for contacting the callee
>       might be used.
>
> O.K.?


Yes, and you might even substitute "might" for the remaining MAY.


>
>
> I think that
>>
>>     A callee MAY choose to listen on both
>>     SIP and SIPS ports and accept calls from either SIP schemes, or
>>     select a single one.
>>
>> is using "SIP schemes" generically, but this might be clearer if you just
>> said "either scheme".
>>
>>
> O.K., done.
>
> I'm not on top of SIPS these days, but I didn't think
>>
>>     SIPS requires end-to-end protection that may include client links and
>>     endpoint certificates.
>>
>> was "end-to-end protection". Is it? I thought that it was
>> protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP?
>>
>>
> oops, that's a lapse. It should be all links including client links (if
> present). So we propose to rephrase
>
>     SIPS requires protection of all links that may include client links
> (if present) and
>     endpoint certificates.
>
> Sorry if I'm confused (and the SIP Forum will be thrilled to hear this,
>> if I'm just confused).
>>
>> I can figure out what "fork explosion" and "fork bomb" are, but are these
>> terms in common usage in the SIP community? Is there a definition or
>> reference for them?
>>
>>
> I could not find a document defining exactly these terms (or equivalents),
> but the phenomena are broadly discussed (e.g. RFC 5393). I'm happy to
> rephrase, if there is a term striking better - any suggestions?


I really like those terms. Could you add a phrase to define them? Perhaps,
"an attack using SIP forking to amplify the effect on the intended victim",
or some such?

(I think "amplify" might be more common in other communities, but I really
do like your terms. Somewhere, Dean Willis is smiling)


> Thanks again,
>
>  thomas


Oh, thank you. I was hoping I remembered this much of P2PSIP!

Spencer