Subject: [OPSAWG] Secdir last call review of draft-ietf-opsawg-nat-yang-14

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Jun 2018 13:06:32 -0700

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. If this transitions from
T->F then what is the implementer supposed to do? 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,
hence the suggestion to really put it out of scope rather than try specify it 
fully.)

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.

---

From: <[email-masked]>
Date: Mon, 18 Jun 2018 07:10:18 +0000

Hi Stephen, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[email-masked]]
> Envoyé : dimanche 17 juin 2018 22:07
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked]
> Objet : Secdir last call review of draft-ietf-opsawg-nat-yang-14
> 
> 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). 

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. 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 think that illustrates
> the

[Med] There is already RFC 8158.

> hence the suggestion to really put it out of scope rather than try specify it

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

> maybe just delete the 1st sentence.

[Med] OK.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 18 Jun 2018 10:48:43 +0100

Hi Med,

On 18/06/18 08:10, [email-masked] wrote:
> Cheers, Med
>> -----Message d'origine----- De : Stephen Farrell
>> [mailto:[email-masked]] Envoyé : dimanche 17 juin 2018
>> 22:07 À : [email-masked] Cc :
>> [email-masked]; [email-masked];
>> [email-masked] 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.

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

---

From: <[email-masked]>
Date: Mon, 18 Jun 2018 11:13:38 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : lundi 18 juin 2018 11:49
> À : BOUCADAIR Mohamed IMT/OLN; [email-masked]
> Objet : Re: Secdir last call review of draft-ietf-opsawg-nat-yang-14
> 
> 
> Hi Med,
> 
> 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
> data retention duration and scope, for logging that is local

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

> this draft, and maybe consider working on some other interface

[Med] ACK.