Re: [Netrqmts] New Version Notification for draft-odonoghue-netrqmts-02.txt

Tim Wattenberg <mail@timwattenberg.de> Wed, 20 November 2019 10:52 UTC

Return-Path: <mail@timwattenberg.de>
X-Original-To: netrqmts@ietfa.amsl.com
Delivered-To: netrqmts@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7583120857 for <netrqmts@ietfa.amsl.com>; Wed, 20 Nov 2019 02:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 5R5tkEVxYKHF for <netrqmts@ietfa.amsl.com>; Wed, 20 Nov 2019 02:52:44 -0800 (PST)
Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EBD120814 for <netrqmts@ietf.org>; Wed, 20 Nov 2019 02:52:43 -0800 (PST)
Received: from smtp1.mailbox.org (smtp1.mailbox.org [80.241.60.240]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 47Hzzr0HCyzKmLK; Wed, 20 Nov 2019 11:52:40 +0100 (CET)
X-Virus-Scanned: amavisd-new at heinlein-support.de
Received: from smtp1.mailbox.org ([80.241.60.240]) by spamfilter06.heinlein-hosting.de (spamfilter06.heinlein-hosting.de [80.241.56.125]) (amavisd-new, port 10030) with ESMTP id tg-l9ZLSapsc; Wed, 20 Nov 2019 11:52:36 +0100 (CET)
From: Tim Wattenberg <mail@timwattenberg.de>
Message-Id: <4173E09C-4599-4F18-983F-A389A5384C4C@timwattenberg.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_523116C6-2027-48DB-9B3A-09B853FE94E9"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 20 Nov 2019 18:52:31 +0800
In-Reply-To: <C7C9F643-AC91-492B-88AE-C869BD7EB468@gmail.com>
Cc: netrqmts@ietf.org
To: Bob Hinden <bob.hinden@gmail.com>
References: <157290772945.13855.16351216204560466911.idtracker@ietfa.amsl.com> <55AACF28-576A-42E4-8FD7-E082482AF43B@gmail.com> <2542B8F5-A2CD-4F7D-81F9-E60C5021384D@timwattenberg.de> <C7C9F643-AC91-492B-88AE-C869BD7EB468@gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netrqmts/e814k48JxF7FmFTJKgg4QZSxGso>
Subject: Re: [Netrqmts] New Version Notification for draft-odonoghue-netrqmts-02.txt
X-BeenThere: netrqmts@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Meeting Network Requirements <netrqmts.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netrqmts/>
List-Post: <mailto:netrqmts@ietf.org>
List-Help: <mailto:netrqmts-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netrqmts>, <mailto:netrqmts-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2019 10:52:47 -0000

Thanks Bob. I added some comments as well.

> Am 20.11.2019 um 18:17 schrieb Bob Hinden <bob.hinden@gmail.com>om>:
> 
>> On Nov 17, 2019, at 2:53 PM, Tim Wattenberg <mail@timwattenberg.de> wrote:
>> 
>> --- Section 2 "Requirements for Internet Connectivity“
>> 
>> I'd extend the bullet point "The provider(s) MUST allow the IETF to advertise (from the IETF AS number) the IETF IPv4 and IPv6 address ranges.“ with "There MUST exist RPKI ROAs for the address space announce by the IETF.“

Just to be sure: Might you have missed this point?

>> I might misunderstand something, but could you point out the difference between "The transit provided […] MUST be capable of providing access to the IPv4 and IPv6 default free zones […]“ and "The provider(s) SHOULD carry and advertise full BGP tables.“?
> 
> Fair question, but I note that the first one also says:
> 
>   *  The transit provided in support of the IETF MUST be capable of
>      providing access to the IPv4 and IPv6 Default Free Zones [DFZ].
>      without the imposition of content filtering (e.g., URL, Site,
>      application, port, or Deep Packet Inspection (DPI) filtering).
> 
> I think the important part of the first paragraph is “without the imposition of content filtering…”   We want an open Internet connection without any kind of filtering.  I think this is an important requirement.

Totally agree with you here. A subsequent observation I didn’t express before is, that one sentence uses MUST, the other one SHOULD.
To emphasize that we do not want any content filtering, how about:

"The transit provided in support by the IETF SHOULD/MUST carry and advertise full BGP tables and SHOULD/MUST be capable of providing access to the IPv4 and IPv6 Default Free Zone [DFZ]. The provider(s) MUST NOT impose any content filtering (e.g., URL, Site, application, port, or Deep Packet Inspection (DPI) filtering)."

(Please choose the desired requirements language.)

>> Also, section 2 only talks about the measures the transit provider(s) are supposed to take. The IETF itself also can do (and probably does?) route filtering/OV. However, text for this would probably go into section 4?
> 
> I am not sure.  Other comments?
> 
>> "The provider(s) SHOULD implement BGP communities, especially the ability to RTBH.“
>> Besides from RTBH, do you have other use cases in mind to explain a little what you mean by this point?
> 
> I am not sure.  Other comments?
> 
>> --- Section 3 "Meeting Facility Requirements“
>> 
>> "All locations for network gear, with the exception of wireless APs, MUST be secure.“
>> I think that's *very* broad. Maybe we can add against what they must be secured (e.g. "[…] MUST be secured against unauthorized access“?).
> 
> I agree this should be more clear.   Please suggest text.

Other than the text I suggest in my original email, I’m not sure about additional security-requirements. Maybe the NOC can clarify and indicate whether my proposed addition misses something.

>> --- Section 4 "Internal Network Requirements“
>> 
>> Addition: "If not provided by the meeting facility, wired Ethernet connections (network drops) MUST be provided by the IETF NOC […]“.
>> To make it even more clear that section 3 talks about our requirements towards the meeting facility and section 4 talks about the different use cases within the IETF.
>> 
> 
> I am not sure it is practicable for the IETF to run cables in venues these days.

Understood. If we do not run cables, I think we can drop this point since it should be covered in section 3 with the meeting facility requirements (or clarify it there).

>> There is one additional thing I’d like to see mentioned somewhere:
>> "The network MUST NOT log or collect user payload data.“ (or something along those lines).
>> 
> 
> Maybe we need to add a Privacy Section (or similar) to the document.

Good idea. Who provides some text?
(I’d be happy to so, but I think I might not have sufficient insight.)

Thanks, Tim.