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

[<[e-mail]>]

Re-,

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Stephen Farrell [mailto:[e-mail]]
> Envoyé : lundi 18 juin 2018 11:49
> À : BOUCADAIR Mohamed IMT/OLN; [e-mail]
> Cc : [e-mail]; [e-mail]; [e-mail]
> Objet : Re: Secdir last call review of draft-ietf-opsawg-nat-yang-14
> 
> 
> Hi Med,
> 
> On 18/06/18 08:10, [e-mail] wrote:
> > Hi Stephen,
> >
> > Thank you for the review.
> >
> > Please see inline.
> >
> > Cheers, Med
> >
> >> -----Message d'origine----- De : Stephen Farrell
> >> [mailto:[e-mail]] Envoyé : dimanche 17 juin 2018
> >> 22:07 À : [e-mail] Cc :
> >> [e-mail]; [e-mail];
> >> [e-mail] 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.
> >