> > > > Le 25 oct. 2010 à 16:37, Chris Engel a écrit : > > > 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. > > My point is that if I have the choice, I will chose a vendor > that doesn't require that I manage its CPE to obtain IPv6 > incoming connectivity. Vendors clearly do what they want, but > their clients too. >
Remi, that's great. I don't think anyones trying to tell you what vendors you must choose or your vendors what choices they must make in thier deployments. That's kinda been my whole point all along. The only thing which I THINK is being said is... hey under many NATv44 deployments certain things were true, under NATv66 those things are no longer true. If you want a way to recover some of that same functionality, you can do this. Heck, were I a vendor responsible for deploying CPE for public end users under IPv6 (I'm not), I think I would actualy give clients a CHOICE of which way thier CPE was delivered to them when provisioning services... with a little plain language explanation of what each choice meant...and nice little radio button/check box for them to indicate thier choice. How crazy is that? > > > 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. > > Yes, but there are places where there are so many protection > codes to remember that people, especially if they are old, > can't even re-enter their homes. Staying at home is one more > protection against accidents in the streets, but it isn't > necessarily the wisest choice. > Depends on the situation of usage case involved. Not all situations are the same. The door to your storage shed and the door to a missle silo at NORAD are both doors and they both need to support being opened and closed....but the circumstances under which that occurs is very different in each case. The first step in any security evaluation is a RISK ASSESMENT... understanding the relatives risks involved, the consequences for failing to address them, and the cost on all levels (that includes functionality/ease of use complications) which is appropriate to mitigate those risks. The right choice for your storage shed is not neccesarly the right choice for NORAD's missle silo. However the designers of something as basic in concept as "a door" need to be able to account for both communities of users and everything in between in thier design. Right now, you are only thinking from the aspect of one community of users. > > > 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. > > Some security professionals may like to arouse fear, > uncertainty, and doubt. > > But, again, many users already use "native" IPv6 (neither > 6to4 nor Teredo) and no bomb has exploded. And AFAIK no bomb > is timed to explode either. > > > 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. > > Of course, if you could show that some IPv6-capable OS's > accept dangerous incoming connections by default, this would > be useful, but AFAIK this isn't the case. > Sure... Windows Vista, Windows 7, Windows Server 2008, and any number of "IP capable" printers/fax's/scanners/garbage disposals, etc. The whole point behind the principle of multiple security layers is that devices/OS's are designed and configured by human beings and thus subject to unexpected flaws. If this weren't true then you would never see any vendor issue a security patch, ever. > > > 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. > > I have tried to explain. > E2e address preservation is a key advantage of IPv6 that > shouldn't be lost from the outset. > > RD It's only being lost where the people responsible for these systems WANT to loose it. That was even true under IPv4....at least until address shortages became an issue. Under IPv6 the address shortage issue goes away...and thankfully that community of users who WISH to preserve e2e address transparency can get to do so. However, what about the community of users who DON'T want to preserve e2e address transparency. I don't think there is anything in this or any other proposed standard (for the general public) which says NAT MUST be deployed when you deploy IPv6. > > > > > > > > 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 > >> > > > Christopher Engel Network Infrastructure Manager SponsorDirect [email protected] www.SponsorDirect.com p(914) 729-7218 f (914) 729-7201 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
