It's a little off subject, but vendors are going to do whatever they think serves thier customers best. I'm not sure what, if anything, that would have to do with a NAT66 standard.
Vendors who are concerned about thier clients security are not going to offload responsibility for that security entirely on the OS, that would be irresponsible of them. It's well known in security that a best practice is to provide multiple layers of defence...that would mean blocking packets at the network boundary (CPE) AND on the individual device level. This becomes especialy important in the IPv6 world...where we are starting to see OS's and devices come enabled with IPv6 connectivity by default...and your average end user may not even be aware that such connectivity exists, let alone how to account for protecting it. IPv6 is a huge security time bomb, waiting to happen...as has been written about by many security proffesionals. Regardless, that has very little to do with NAT66. The flavor of NAT, the authors are proposing here neither prevents nor mandates filters which would block traffic. A mention or reference about security issues sounds like a pretty responsible thing for the authors to do...since NAT in IP4 featured statefull inspection and at least many to one NAT (the type I would actualy like to see exist in IPv6) had some functionality to block incoming connections by default. Many organizations relied on this as an extra layer of protection for thier internal infrastructure..... and many vendors (wrongly) used it on CPE as a weak sort of firewall. Most folks I think should be able to figure out from the fact this is stateless, that such functionality has been depricated. However, I don't see anything wrong with the authors mentioning that it may be prudent to consider FW filters for blocking incoming connections if a vendor wanted to recover some of that same functionality that existed in IPv4 Dynamic NAT. Christopher Engel Network Infrastructure Manager SponsorDirect [email protected] www.SponsorDirect.com p(914) 729-7218 f (914) 729-7201 > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Rémi Després > Sent: Monday, October 25, 2010 9:36 AM > To: Margaret Wasserman > Cc: Roger Marquis; [email protected] > Subject: [SPAM] - Re: [nat66] Fwd: New Version Notification > for draft-mrw-nat66-00 - Email has different SMTP TO: and > MIME TO: fields in the email addresses > > > > Le 25 oct. 2010 à 15:03, Margaret Wasserman a écrit : > > > > > On Oct 25, 2010, at 7:59 AM, Rémi Després wrote: > >> That's what tools.ietf.org/html/draft-despres-softwire-sam-01 sec. > >> 3.3 is about. Provided hosts support it: > >> - e2e addresses are preserved > >> - it works even with an independent CPE per ISP (which > isn't the case > >> with NAT66) > > > > Could you explain what you mean here? As long as both > devices support > > NAT66, NAT66 should work fine in this environment, AFAIK. > > OK, I could have explained more what I was referring to. > This relates to ingress filtering. > If a host sends a packet, it has no way, with NAT66 to make > sure it goes to the right CPE (that of the ISP whose prefix > is at the beginning of the source address. > > > > >> Where they are desired, firewalls have to do their own > work (they by > >> no means need addresses translation for this). > >> > >> Per se, the stateless mechanism proposed by Margaret and Fred in > >> their NAT66 draft, does break e2e address preservation, > but doesn't > >> do anything to prevent incoming calls. (Their NAT66 draft says: > >> "RECOMMENDED that NAT66 devices include an IPv6 firewall function, > >> and the firewall function SHOULD be configured by default to block > >> all incoming connections."). > > > > This is stated specifically to discourage vendors from shipping a > > product that, by default, blocks all incoming connections for IPv4 > > (due to the IPv4 NAT functionality) and does not block inbound > > connections for IPv6. > > IMHO, for unmanaged CPE's they should rather be encouraged > than discouraged: > - Free's customers have been using such products successfully > for years now. > - Being among them, I prefer this product behavior to that > you suggest. > - If punching holes in CPEs become as necessary in IPv6 as in > IPv4 to have incoming connections, the main advantage of IPv6 is lost. > > Every OS that supports IPv6 has AFAIK its internal FW, at > least to the point where its doesn't accept unwanted incoming > connections. > > > > The advantage to separating the NAT and firewall functionality, > > though, is that with NAT66, enterprise administrators _can_ enable > > whatever inbound connectivity they like. Every node can be made > > accessible on all of its available ports, using a a > distinct address > > per node. > > > At the time I wrote this, the v6ops group was (I think) > recommending > > that all sites deploy firewall functionality in IPv6. > > I consistently opposed that. > Fortunately it has become a vendor responsibility to decide > whether unmanaged CPEs are shipped with transparent mode by > default or not. > > My hope is that the majority of vendors of IPv6-capable > unmanaged CPEs will understand that the transparent mode is > the one that favors IPv6 deployment: > - no need to manage CPEs to take advantage of incoming connectivity > - unwanted incoming connectivity is filtered by OS internal firewalls > > > I've been told more recently that I should check what those > > recommendations actually were, to make sure I am aligned and/or > > reference them rather than stating the recommendation here, which > > would be fine with me. > > IMHO, a reference would be better than alignment (but both > work for me). > > Regards, > RD > > > > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
