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
