Re: [Captive-portals] Opsdir last call review of draft-ietf-capport-rfc7710bis-04

Tim Chown <Tim.Chown@jisc.ac.uk> Fri, 15 May 2020 08:25 UTC

Return-Path: <tim.chown@jisc.ac.uk>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1F23A00D5 for <captive-portals@ietfa.amsl.com>; Fri, 15 May 2020 01:25:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
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 N_NgNTqPmJq5 for <captive-portals@ietfa.amsl.com>; Fri, 15 May 2020 01:25:03 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C27673A00D8 for <captive-portals@ietf.org>; Fri, 15 May 2020 01:25:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1589531100; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0hPRURSONLd+2kBG8PJx8117/+pyMwoWSwV+1xIhrMo=; b=WfkQMFtzTfOL34VvIa0n0VY6fXXvZk1gFBPbtsB5jw9EnHZTRHiACwGzJjCRrikec+F97n AyDNHKeT+gjzsxeSQB37QRHENSll+5wxtdAzVgT6tTlLHMiuNnUzpIWudVUYGNYnwQ+FFr FEk1Nl/ViGIcrtNKLJxbWIH3iP8q9BE=
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04lp2053.outbound.protection.outlook.com [104.47.13.53]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-272-9SPS7yb-NLie26ncA97JFg-1; Fri, 15 May 2020 09:23:42 +0100
X-MC-Unique: 9SPS7yb-NLie26ncA97JFg-1
Received: from DB6PR07MB3224.eurprd07.prod.outlook.com (2603:10a6:6:21::19) by DB6PR07MB4325.eurprd07.prod.outlook.com (2603:10a6:6:53::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.14; Fri, 15 May 2020 08:23:40 +0000
Received: from DB6PR07MB3224.eurprd07.prod.outlook.com ([fe80::9463:3455:5708:8afe]) by DB6PR07MB3224.eurprd07.prod.outlook.com ([fe80::9463:3455:5708:8afe%6]) with mapi id 15.20.3021.010; Fri, 15 May 2020 08:23:40 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Erik Kline <ek.ietf@gmail.com>
CC: "ops-dir@ietf.org" <ops-dir@ietf.org>, "draft-ietf-capport-rfc7710bis.all@ietf.org" <draft-ietf-capport-rfc7710bis.all@ietf.org>, captive-portals <captive-portals@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-capport-rfc7710bis-04
Thread-Index: AQHWKjvulqP9t8k0/UuRwlSleo7oYKiozt0A
Date: Fri, 15 May 2020 08:23:40 +0000
Message-ID: <0166C59E-67E7-4616-9F2B-E134497F8B78@jisc.ac.uk>
References: <158946663438.14648.1075495401260934099@ietfa.amsl.com> <CAMGpriUnrPcsvSSvDReR9fYX-PeLwM7G2Ktfn4eW5g8-JYxTkg@mail.gmail.com>
In-Reply-To: <CAMGpriUnrPcsvSSvDReR9fYX-PeLwM7G2Ktfn4eW5g8-JYxTkg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.80.23.2.2)
x-originating-ip: [212.188.254.49]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1c437a8b-c4a7-4022-9ab9-08d7f8a945ee
x-ms-traffictypediagnostic: DB6PR07MB4325:
x-microsoft-antispam-prvs: <DB6PR07MB4325F2139B57CB24C45046A1D6BD0@DB6PR07MB4325.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 04041A2886
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: RCeFH+YncQZdrpLeMFoovowZ3t443iTlBrdYTT7z8BVe3h9m2wL169gT6xpiRgo38qi6hVPmxCUR5F1rkM/dmVZXkbJYs5sd5Rzeuw67KReFLC7v9g/m0aEkFc6vqYQO6tjRoSr32WjtJCJr/vLcdoWvks4F5S0oQQomYSBsYe+R8ya/7ttoMM/Fug6VmyuvBuwpnZtqo+CFbX8noeJSi3cYMzS55a4IYRE5oYQBq7NDUsxHlf5OQ5cbIHEcs4WlAI5yKXJqIco56VHWAngMIUB/2PnvT6RK3ujEPC0lQAo+pmj+lZZ8cN4RvBQX60aeDeV3lDy1Kq/3bXpAU956mZKrxhp7Ueh7FhgW6/c6MoH9RAhoRxUR69WQ6VpWHpRfdSvLIdYbsUTnnSo8Rv7M6nBu9tSM+Js19kDHMK366oLetlM3MRtBDaKV4kucI6q9AtPLyxqISboXwhc48eKQM77Zy7zU2QXPeyVDIUfkwkpKAVDHEiVRkxK9faCURtGRxJbkcvD4rmE9+CNZ46VDDA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB6PR07MB3224.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(366004)(39850400004)(376002)(396003)(8936002)(2616005)(6486002)(86362001)(6506007)(316002)(786003)(54906003)(2906002)(8676002)(6916009)(4326008)(186003)(33656002)(71200400001)(53546011)(66946007)(66446008)(76116006)(66556008)(36756003)(26005)(91956017)(966005)(55236004)(6512007)(478600001)(64756008)(5660300002)(66476007); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: Us5Ga+flea22+79EqBR6e8pjK4rSGuP3UU4ocl/+tXszqTmaU5y+STjIwCzY6Z8scdNwAbXeDDDVtRq0xI4nl0DMR1RjVYdVRktYjXFEnEfcfrmKuG3DG6VdD2TbCkdz1r5lGCpy+ErPQnzdPiXmNGGyDO64bmh85Eu6htmUitvUtKLQnMxJoBLaUIym2I2w2qP6pl4OGHaXojMtb1s+/3WFUIwHNtmLd32VuD08EEHnrfAoaFTIY/gEXSajDZPknBTrgctOp9eCe9PbcyToHr7sRW9L15iUxuJ2DmfiLxOhNlCbk0Tpa55EmOF4MOj7CAxSL3Uz2au3rELzLZZwfyUolDzo/xbUNuppISSoRY3/iZRAxkP038G49mMSheJh77RRSHDfsFmwLgsGjxdYTuIhZ0ER5TrYIzE5QdNMI1qaR81PVeURy4tgr2NS5nt5r4Uo2lbi3DyMH5tsy31d3OYrdJKgjmvzB+uk1W+8ByZh6M1kfWXmuDaaxZRRQjtc
x-ms-exchange-transport-forked: True
Content-ID: <C170DB152EB99947A635D44207E74FDE@eurprd07.prod.outlook.com>
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 1c437a8b-c4a7-4022-9ab9-08d7f8a945ee
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2020 08:23:40.2351 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Jw06URgyw3BR6NTHHqQoafyFIj/2DILYu4nw6UZ00EScJHyhCXUVOPnmHQPHLFB+E9ZYARVah+n+Yv/By/2COQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB4325
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: jisc.ac.uk
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/TDLBTvbWBWNWkqSHtv-yc_1x0yw>
Subject: Re: [Captive-portals] Opsdir last call review of draft-ietf-capport-rfc7710bis-04
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 May 2020 08:25:06 -0000

Hi Erik,

All sounds good, apologies I missed the 05 posted the same day.

Best wishes,
Tim

> On 14 May 2020, at 23:06, Erik Kline <ek.ietf@gmail.com> wrote:
> 
> Tim,
> 
> Thanks for taking the time to read and comment.  Replies inline below
> and changes made at https://github.com/capport-wg/7710bis .
> 
> On Thu, May 14, 2020 at 7:30 AM Tim Chown via Datatracker
> <noreply@ietf.org> wrote:
>> 
>> Reviewer: Tim Chown
>> Review result: Has Nits
>> 
> ...
>> 
>> General comments:
>> 
>> The security considerations (Section 5) talk of potential spoofed DHCP or RA
>> captive portal option messages; equally an attacker could use a rogue RA or
>> DHCP message to convey (for example) a bad DNS server option, which could
>> direct a client to a bad captive portal endpoint.  So the document should
>> probably state that there is an assumption of RFC 6105 (RA Guard) or equivalent
>> measures being in place; whether such a capability is realistic in a coffee
>> shop scenario is another question.
> 
> As part of feedback from a security review we've added text and
> references to RA Guard and DHCP Shield.
> 
>> I also wonder how commonly multiple provisioning domain scenarios will arise
>> for school network access, where a client may see multiple captive portals. I
>> note that draft-ietf-intarea-provisioning-domains-04 seems to have expired, so
>> I’m not clear whether that initiative has been dropped; it seemed to have good
>> potential.
> 
> The PVD doc is in the editors' queue.
> 
>> Nits:
>> 
>> Abstract:
>> 
>> * Clarify that the document describes and DHCPv4 and DHCPv6 option.
> 
> done
> 
>> * Remove the parantheses from the RA option text; these are “equal” options.
> 
> done
> 
>> * Perhaps rewrite “it is designed to be used in larger solutions“ to “it is
>> designed to be one component of a standardised approach for hosts to interact
>> with such portals.“
> 
> sounds good; done
> 
>> * And perhaps rewrite “The method of authenticating to, and interacting with
>> the captive portal is out of scope of this document.” to “While this document
>> defines how the network operator may convey the captive portal API endpoint to
>> hosts, the specific methods of authenticating to, and interacting with the
>> captive portal are out of scope of this document.”
> 
> also good; done
> 
>> Section 1:
>> 
>> * This cites RFC 2131 for DHCP; I’d suggest citing RFC 3315 and RFC 8415 and
>> emphasising that there are options for DHCP for IPv4 and DHCPv6.
> 
> changed to 2131 for DHCPv4 and 8415 for DHCPv6 (3315 was obsoleted by 8415).
> 
>> * It also says “how to contact an API”; probably better to say “the API
>> endpoint that the host can contact” as the “how” is out of scope for this
>> document.
> 
> done
> 
>> Section 2:
>> 
>> “Implement the interception” -> “implement interception”
> 
> done
> 
>> Section 3:
>> 
>> Second paragraph, is that a “should be logged” or “SHOULD be logged”?
> 
> No strong feelings either way, since it's a device behaviour that no
> user will probably ever see.  Went with SHOULD.
>