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

<mohamed.boucadair@orange.com> Mon, 18 June 2018 11:13 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 DFD24130E96; Mon, 18 Jun 2018 04:13:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 gsjao4f2dUoO; Mon, 18 Jun 2018 04:13:53 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A8F130DDF; Mon, 18 Jun 2018 04:13:52 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 418T4H4dtrz2yl5; Mon, 18 Jun 2018 13:13:51 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id E2E38160098; Mon, 18 Jun 2018 13:13:38 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0399.000; Mon, 18 Jun 2018 13:13:38 +0200
From: <mohamed.boucadair@orange.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "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>
Thread-Topic: Secdir last call review of draft-ietf-opsawg-nat-yang-14
Thread-Index: AQHUBumN98KCqFI0Y0G23qLjJqwx/6Rl2k7Q
Date: Mon, 18 Jun 2018 11:13:38 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302DF469A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <152926599250.2311.15532810595098738604@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302DF4678E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <1c4bf138-afb1-4aef-ddb5-b15262b05af2@cs.tcd.ie>
In-Reply-To: <1c4bf138-afb1-4aef-ddb5-b15262b05af2@cs.tcd.ie>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Wf14PhFSBegBXZ3YNZC8bI_32p4>
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 11:13:56 -0000

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Envoyé : lundi 18 juin 2018 11:49
> À : BOUCADAIR Mohamed IMT/OLN; secdir@ietf.org
> Cc : draft-ietf-opsawg-nat-yang.all@ietf.org; ietf@ietf.org; opsawg@ietf.org
> Objet : Re: Secdir last call review of draft-ietf-opsawg-nat-yang-14
> 
> 
> 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.

[Med] This is deployment-specific. For example, a CGN which is configured to behave in port deterministic behavior (RFC7422) instead of another port assignment scheme does not need to enable logging since the internal IP address/port(-range) is a function of the external IP address/port(-range).

 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.

[Med] Typically, data retention duration is not handled at the NAT itself but as part of a "dedicated" platform that is used to gather logging information from various sources in a network.  

> 
> >
> >> 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.
> 

[Med] ACK.  

> 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.
> >