Re: [secdir] Secdir last call review of draft-ietf-opsawg-nat-yang-14

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 18 June 2018 09:48 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71206130DCC; Mon, 18 Jun 2018 02:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 5jBV8rZa94Ib; Mon, 18 Jun 2018 02:48:47 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F1E1277C8; Mon, 18 Jun 2018 02:48:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28D5DBE2E; Mon, 18 Jun 2018 10:48:45 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbVbrxe_nzm2; Mon, 18 Jun 2018 10:48:45 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DF127BE24; Mon, 18 Jun 2018 10:48:44 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1529315324; bh=2IqN8oJBHeSZP1zO8yk8BmWvDpBClQig4RyfA+Z4Sko=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Z8cCckdjiI9vdHUgwFv9O3tbKKlHtWEfmvo88BJw7E1r/W+zGKEDsiDyWU72njT2S xw/4EbCXgHIDfSxjUOy00KzYSbMWx9ET21Pc8sNoOVaFizJ5dmboCJqO+5kNx7cNL0 oqozcxJ5U2RFy96JTXtSXoK57uoMNixpX1MLYNpc=
To: mohamed.boucadair@orange.com, "secdir@ietf.org" <secdir@ietf.org>
Cc: "draft-ietf-opsawg-nat-yang.all@ietf.org" <draft-ietf-opsawg-nat-yang.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>
References: <152926599250.2311.15532810595098738604@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <1c4bf138-afb1-4aef-ddb5-b15262b05af2@cs.tcd.ie>
Date: Mon, 18 Jun 2018 10:48:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dMyLed2VmvreUswV1UzhTlEZptsFSuARy"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/MhBma4EdNgG-LzDXyUJO0WRiAk4>
Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-nat-yang-14
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2018 09:48:51 -0000

Hi Med,

On 18/06/18 08:10, mohamed.boucadair@orange.com wrote:
> Hi Stephen,
> 
> Thank you for the review.
> 
> Please see inline.
> 
> Cheers, Med
> 
>> -----Message d'origine----- De : Stephen Farrell
>> [mailto:stephen.farrell@cs.tcd.ie] Envoyé : dimanche 17 juin 2018
>> 22:07 À : secdir@ietf.org Cc :
>> draft-ietf-opsawg-nat-yang.all@ietf.org; ietf@ietf.org;
>> opsawg@ietf.org Objet : Secdir last call review of
>> draft-ietf-opsawg-nat-yang-14
>> 
>> Reviewer: Stephen Farrell Review result: Has Issues
>> 
>> I see one major issue:
>> 
>> 2.1: Logging in NATs and esp. CGNs is clearly sensitive in various
>> ways. I think it'd be ok if logging was really out of scope,
>> however, there is a logging-enable feature, I think
>> under-specified,  (on page 63) so the statement in 2.1 seems
>> contradictory to me - if logging is out of scope why is 
>> logging-enable a flag?.  Presumably if logging-enable transitions
>> from F->T then you turn on (some undefined kind of) logging.
> 
> [Med] The intent is not to define the exact set of logging
> information (e.g., Section 4 of RFC6888), the protocol to use (e.g.,
> RFC8158 or draft-ietf-behave-syslog-nat-logging), etc... but to allow
> for disabling/enabling such feature (when supported by an
> implementation).

Sure, I get the idea. I guess I'm not sure it's a good idea
though, if not more fully specified.

> 
> If this transitions from
>> T->F then what is the implementer supposed to do?
> 
> [Med] This transition will have an effect to disable ANY logging
> feature supported by an implementation. 

Really? I'd have thought there was going to be some logging
that was always on, e.g. to detect attacks. Or maybe you're
not calling that logging? (I think that maybe also illustrates
that as-is, this is currently not very well defined.)

> The transition for F to T is
> more problematic as it requires additional information to be
> available (e.g., logging server IP address and port, credentials,
> ...). The document assumes that data is provisioned using other
> specific modules (syslog, ipfix, etc.).

I suspect that there'd also be a need for information about
data retention duration and scope, for logging that is local
to the NAT box.

> 
>> I think that illustrates
>> the under-specification here. The simplest thing might be to really
>> make logging out of scope here by deleting the logging-enable thing
>> entirely. (I can imagine that reaching consensus on a logging
>> control interface would be non-trivial,
> 
> [Med] There is already RFC 8158.
> 
>> hence the suggestion to really put it out of scope rather than try
>> specify it fully.)
>> 
> 
> [Med] If, with the above clarification, you maintain your comment,
> then I don't have any objection to remove that optional feature from
> the module. Please advise.

Well, mine is just a secdir review - you're not forced to do
anything at all about it (unless some AD decides that you need
to). But FWIW, yes, I do think it'd be better to drop that from
this draft, and maybe consider working on some other interface
to handle it better.

Cheers,
S.



> 
>> Just one nit:
>> 
>> The abstract could do with a bit of re-wording as it reads
>> awkwardly.  I'd say maybe just delete the 1st sentence.
>> 
> 
> [Med] OK.
>