Inline. > On May 3, 2015, at 9:36 AM, GangChen <[email protected]> wrote: > > Thank you for the comments. I'd seen it's great useful to improve the > draft quality. > Please see my reply inline. > > 2015-05-02 4:36 GMT+08:00, JF Tremblay <[email protected]>: > >> 2.4.1 "The storage of log information may pose a challenge to operators, >> since it requires additional resources and data inspection processes to >> identify users." >> The data inspection remark here does not make sense. The NAT might correlate >> source addresses to user information if it has it available, but it won’t >> inspect. The NAT does not store either. > > the issue is a NAT may don't know what source address should be correlated. > Therefore, the NAT have to store entire information preparing the searching. > For your information, the NAT should store at least three-months log > in our networks.
In my opinion: - NATs do not / should not store logs. This is done by an external server (syslog or other). - NATs do not correlate source addresses to users, unless it already has that information available. This can be done offline by a server with much more ressources. This could be guidance to put in this document, if not mentioned elsewhere. (but I thought that was quite obvious) >> 2.4.3: Why not cover port block randomization here as well? > > Good to know more if you point me a reference of "port block randomization”. There isn’t a reference. I might have coined the term a couple of years back, not sure. This is basically the act of randomizing the assignments of blocks instead or in conjunction with port randomization within the block. This could be a concept defined and discussed in this document. /JF _______________________________________________ sunset4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/sunset4
