Hi, Eric, Thanks so much for your feedback! Please find my comments in-line....
On 10/05/2015 12:57 PM, Eric Vyncke (evyncke) wrote: > Fernando, Fred and Paul, > > Sorry for belated reply, here are a couple of comments: > > The title is a little ambiguous IMHO it is "On Firewalls in Security" > (because they also apply inside an 'intranet') or "On Firewalls in > Internet Protocol (IP) Security" or "On firewalls and Security of the > Internet" ? How about "On Firewalls in Network Security"? > The introduction looks more like an history, so should perhaps be renamed? How about splitting the historical part into a stand-alone section renamed as "Firewalls in the IETF" or the like? > Terminology section should perhaps appear more like an usual terminology > section and not as a free-form text? mm.. I guess that from the current contents we can define "firewall" and "perimeter"? > Section 3.2 (end to end principle) is interesting but is a little complex > to read. Any suggestions on how to improve the text? > Section 3.3, unsure whether I am reading it correctly but I don't agree > with the statement that firewall can protect the (network) infrastructure > against DoS attack (as hinted by "message volume overwhelms"). Rate > limiters or DoS scrubbing devices do not qualify as 'firewall' IMHO. Could you elaborate a bit? e.g., why wouldn't a rate-limited qualify as a firewall? > I think section 3.4 (a good one) rather belongs to section 4 and should > align the taxonomy. Yep. Looks like we could move this into the base Section 4. (Or were you meaning something else?) > Section 4.1, split the first paragraph in two parts. The second one being > the example given => to make it clear that the "sessions may never be > initiated from the outside" belongs to the example only OK, will do. > Section 4.1, 2nd paragraph, the word 'testing' has an active tone in my > (non native) English, why not using a more passive verb such as "inspect" > or "check" ? Agreed. Will do. > Section 4.1, at the risk of appearing as 'purist', I would move the NAT > section from this section and create one on this topic. Please let me think about this one. f you have any suggestions regarding whre in the I-D you'd put such a section, please let me know. > Section 4.2, or rather the perimeter exists but it very very small : one > physical link :-) or wider: one logical perimeter without any strict > geographical boundaries. Yes. :-) > Section 4.2, should make it clear that the 'tagging' is required (being > IEEE 802.1Q VLAN tag or ...), OK. > and, the end of the section is rather > negative on this specific FW. I see... any hints for improvement? > Section 4.3, I like it of course :-), and I agree there are now scalable > algorithm to detect anomalies even with a single node (thanks to > self-learning :-)) Could you elaborate a bit? :-) > Section 4.3, "Reputation databases have a bad reputation" is a fun > sentence :-) Indeed! :-) > Section 5, I would also use the words of white and black lists as they are > well-known. I wonder also why there is a specific section 5.1 without a > section 5.2? Section 5.2 was forthcomming... (will hopefuly be there in version -01 of the I-D) > I would remove this heading and keep the text. Don't forget > to mention HTTP 2.0 & works such as QUIC. Will do. > Section 6, should also mention that FTP & SIP can be used for dynamic > ports. Will do. > It should also mention/repeat that port 80 is not only about HTTP > but for many protocols 'tunneled' over HTTP. Will do. > Section 6, temporary addresses are indeed annoying in some cases but IP > addresses can also be spoofed. What we meant here is that things like IPv6 temporary addresses change such assumption. But yes, we should comment on spoofing. > Should mention anti-spoofing? And/or IPSEC > AH? Anti spoofing in terms of RPF, or something else? > Section 7 is about layer-3/layer-4 'packet filtering' which is a specific > kind of firewalls while the I-D title appears to be more generic. I > suggest to keep the section but make title more specific and add some > introduction sentences to this section. Good grief! Will do. > Section 8, kind of repeats a former point... Useful text but should unify > and at a single location You mean with Section 4.1? > Section 10 is of course looking for heated comments from the community... [FWIW, Section 10 will be split into a different document... such that the heat happens elsewhere :-) ] > Here are a couple: > - wonder whether the IETF could have recommendations for all cases? Certainly not for all -- but better to have something covered, than nothing :-) > Moreover, situation will probably continue to evolve > - zone-based should also allow ICMP inbound ;-) .... if they relate to an ongoing session? > There are also important (IMHO) topics MISSING: > - more and more traffic are encrypted, good for privacy, bad for firewalls > as they are blind now and mostly useless Yes and no. If you mean TLS, it prevents DPI, but still allows for filtering based on port numbers... > - recommendation for NOT BLOCKING traffic over the Internet (except to > each ISP own infrastructure)? not blocking which sort of traffic? > - logging / auditing function is missing (talking about security here) > - logging of event is missing (talking about operation here) Do you mean in the recommendations section, or elsewhere? Thanks so much! Best regards, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area