I'll try the horrible Outlook to reply using text, please beg my pardon if this is not formatted properly.
On Thursday, June 16, 2016 2:17 PM, Mark Smith [mailto:[email protected]] wrote: >> Hi, >> >> NAT can be still necessary in IPv6 in dual-stack scenario, for instance, >> where every host is assigned both a IPv4 and IPv6 addresses and the >> CGN equipment can't handle them differently. >Can you provide an example of this sort of CGN device. I would prefer not to make names, but you would be unpleasantly surprised. Anyway, it is also not just a matter of not being able to configure them in a certain way (which is possibly the case), but also the case in which they don't work properly. > IPv4 and IPv6 have to be handled differently because they're different > protocols, requiring different code. A single device might be > performing NAT on IPv4 traffic it receives and doing standard stateless > forwarding of IPv6 traffic. Is that the scenario you're describing? Yes, for instance. Or, they handle certain functions (e.g. NAT) purely in the data plane as they are logically simple to be implemented in firmware, while more complex functions (like implementing ULA addresses translation) requires routine engines to be involved, therefore involving different latency for execution. It is pretty common that customers with ISPs offering dual stack, to experience a higher latency for their connection once they implement IPv6 along with IPv4. This does not apply when only IPv4 or only IPv6 are used. Another requirement is that a specific logging or monitoring system is implemented (especially for legal requirements), and this is done through logging NAT translations. An ISP implementing IPv6 along with IPv4 would be in that situation. Luckily, router vendors are moving away from the antiquate architecture which separates data and management plane, for various reasons. This is also why we published draft-gont-opsec-ipv6-firewall-reqs-03.txt, to make it explicit that this should not happen. (I am aware this is off-topic, just making my point :-)) >>Unfortunately RFC 4864 does not mention such case, AFAIK. >> > In any case, I am happy to concede it could be an extreme case and that it is > not necessary anymore in IPv6 for the great majority of use > cases. Okay >> I was not really making a specific case for IPv6 - my opposition was to the >> concept that NAT is not security, and to the fact that it should be >> written as such in the RFC. > So this draft is purely about IPv6. There will be a lot of IPv4 security > measures that can be applied to IPv6, however there will also be others > that shouldn't, and opportunities where IPv6 can provide better security that > IPv4 (e.g. sparse host addressing in a /64 makes address probing > to discover hosts impossible within a useful and practical timeframe.). Okay, I have nothing to object on this. >> NAT *does* provide a form of security >What specific security does it provide that is due to the address translation >function? > If you're thinking about the protection provided due to the state being > created during the address translation process, that state can be > created without performing address translation, which is what a stateful > firewall does and did in IPv4 before NAT became widely deployed. I totally agree with you. I am actually referring to the possibility to hide the systems behind the NATted interfaces of the router/firewall, not just their addresses but also ports and services. If you only apply filtering, you are protecting - but not hiding. In a perfect world, you have such good filters that you can transparently provide the real addresses and ports from clients to the rest of the Internet - however we don't live in such world, therefore hiding provides an additional layer of protection in the "defence in depth" approach. The fact that this "hiding" actually hinders the deployment of many services and makes life worse to engineers in many cases, is another topic on which we agree totally :-) There are also cases where NAT offers better (or at least simpler) protection than filters. For instance, there are known "overbilling attacks" performed in telco networks, where mobile terminals are sent with UDP packets to keep them alive even if would actually disconnect, causing them to be excessively billed. Filters for those situations tend to be complicated and need to understand the Layer-7 protocol running over UDP to protect the terminals; NAT offers a straightforward protection, instead. PS. I am aware that major firewall vendors implement filters against overbilling attacks; I was only making an objection to the semantic of the sentence: NAT *provides* security, saying the contrary is not correct. Whether this could be achieved in some other ways is another matter. >> - the fact that it is not desirable or it is unnecessary to use is another >> topic, in which I believe we all agree (at least for 99% of use cases ;-)) > > I don't see a need to deploy NAT with IPv6 as what has been achieved with > IPv4 NAT can be achieved in IPv6 without the drawbacks of NAT. I mean the same as you do, I would just phrase it as "the poor ISPs which still do that, should consider migrating their architecture to better options". Regards, Marco > >Regards, >Mark. > > 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: Mark Smith [mailto:[email protected]] > Sent: Thursday, June 16, 2016 11:43 AM > To: Marco Ermini > Cc: Brian E Carpenter; Erik Kline; Eric Vyncke (evyncke); > [email protected]; [email protected]; [email protected]; > [email protected]; [email protected] > Subject: Re: [v6ops] [OPSEC] Asking for a review of draft-ietf-opsec-v6-08 > > On 16 June 2016 at 19:15, Marco Ermini <[email protected]> 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. > > > > I personally don't sympathize on NAT-haters. NAT has its reasons, > > especially for carrier-grade NAT > > CGN isn't necessary in IPv6, it's to solve the problem of ISPs running out of > IPv4 addresses. > > and especially in the telco scenario, and yes, it does provide some level of > security - again, not the complete picture, but it does. > > > > NAT is not necessary in IPv6. The equivalent of NAT's perceived security can > be provided via alternative methods, as described in RFC4864. > > A further technique to hide topology that isn't mentioned in RFC4864 is to > use something like ISATAP or similar, to create a single /64 subnet over the > top of multiple IPv4 subnets. Externally, all hosts will appear to belong to > a single IPv6 subnet, hiding the internal topology. > > If you truly want to hide the identities of hosts, NAT doesn't do enough - it > is only translating addresses, where as there are many other host identifiers > that the host itself supplies or will receive and supply that can identify > hosts e.g. HTTP cookies. "A Technique for Counting NATted Hosts" > (https://www.cs.columbia.edu/~smb/papers/fnat.pdf) showed how a field within > the IPv4 header that leaked across a NAT was able to be used to identify > hosts. > > If you truly want to hide a host from the Internet, yet still allow it to > access things on the Internet, under IPv6 your network would use ULA > addressing, and have a per-application protocol proxy server that makes all > requests look like they've entirely originated from the application proxy > server itself. To the Internet server, the application proxy server would > appear to be the application end host making the requests, preventing any > internal host identifiers or other attributes from leaking. > > > Regards, > Mark. > > > > > > 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 > > _______________________________________________ > > v6ops mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
