So, can we agree on "NAT is not required to provide security in IPv6 (see for example [RFC4864])."
I agree that this aspect of IPv6, including the appropriate use of ULAs, is definitely hard to explain to people brought up on common IPv4 practice. Regards Brian On 17/06/2016 23:29, Marco Ermini wrote: > I am sorry Brian, I don't think you understood my argument. I am not arguing > about you mention. I am arguing against the semantic of a phrase that says > "NAT does not provide security". This sentence is semantically wrong, and > usually comes from a priori NAT-haters (I have met a few). > > I am only against stating such sentence in the RFC, not against the fact that > we don't need NAT. I hope this is clearer now. > > Anyway, I have made my point sufficiently, I believe. > > > Regards, > Marco. > > -----Original Message----- > From: Brian E Carpenter [mailto:[email protected]] > Sent: Friday, June 17, 2016 3:40 AM > To: Marco Ermini; Erik Kline; Eric Vyncke (evyncke) > Cc: [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [OPSEC] [v6ops] Asking for a review of draft-ietf-opsec-v6-08 > > On 16/06/2016 21:15, Marco Ermini wrote: >> Well, actually, infrastructure hiding IS part of security. It is not the >> full picture, but it is incorrect to say that it is not. > > Have you read RFC4864 recently? Section 4.4 is all about how you don't need > NAT to hide infrastructure topology in IPv6. > >> I personally don't sympathize on NAT-haters. NAT has its reasons, >> especially for carrier-grade NAT and especially in the telco scenario, and >> yes, it does provide some level of security - again, not the complete >> picture, but it does. > > That's IPv4. This is IPv6. > > Brian > >> >> >> Regards, >> >> Marco Ermini >> >> CISSP, CISA, CISM, CEH, ITIL, MCP, PhD Senior IT Security Analyst D >> +49 (0)899 901 1523 M +49 (0)175 439 5642 >> >> ResMed Germany Inc >> >> >> -----Original Message----- >> From: OPSEC [mailto:[email protected]] On Behalf Of Brian E >> Carpenter >> Sent: Thursday, June 16, 2016 1:45 AM >> To: Erik Kline; Eric Vyncke (evyncke) >> Cc: [email protected]; [email protected]; [email protected]; >> [email protected]; [email protected] >> Subject: Re: [OPSEC] [v6ops] Asking for a review of >> draft-ietf-opsec-v6-08 >> >> On 16/06/2016 07:45, Erik Kline wrote: >>> Section 2.1.2 is far too permissive for my tastes. We need to be >>> able to say that ULA+IPv6 NAT is NOT RECOMMENDED by the IETF. >> >> I have strong sympathy with that statement, but I don't think this is the >> document to do it; the point is made in RFC4864 too. What we should do here >> is underline that NAT != security. >> >> While I'm here, some other points: >> >> "2.2. Extension Headers >> >> TBD, a short section referring to all Fernando's I-D & RFC." >> >> That's not the whole story ;-). Firstly, RFC 7045 has a lot of >> relevance to security aspects. Second, there is no reason to refer to >> most of the material (Fernando's or not) unless it's directly relevant >> to opsec. I think the reference is draft-ietf-opsec-ipv6-eh-filtering, >> but only if that document is going anywhere. >> >> "2.3.3. ND/RA Rate Limiting >> ... >> The following drafts are actively discussing methods to >> rate limit RAs and other ND messages on wifi networks in order to >> address this issue: >> >> o [I-D.thubert-savi-ra-throttler] >> >> o [I-D.chakrabarti-nordmark-6man-efficient-nd]" >> >> Neither of those drafts is in the least active (from 2012 and 2015 >> respectively). Dead drafts are of no help to the reader, IMHO. >> >> "4.2. Transition Mechanism >> >> SP will typically use transition mechanisms such as 6rd, 6PE, MAP, >> DS-Lite which have been analyzed in the transition Section 2.7.2 >> section." >> >> Shouldn't you add RFC6877 464XLAT now? >> >> Finally, I think there should be a Privacy Considerations section. >> >> Rgds >> Brian >> >>> >>> Section 2.6.1.5 could punch up the SAVI stuff a bit more as well. We >>> should, in my opinion, make it painfully clear that DHCP (of any >>> protocol) in the absence of link-layer security/auditability features >>> does not provide any satisfactory way "to ensure audibility and >>> traceability" [Section 2.1.6]. >>> >>> _______________________________________________ >>> v6ops mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> >> _______________________________________________ >> OPSEC mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsec >> > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
