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