> -----Original Message----- > From: Rémi Després [mailto:[email protected]] > Sent: Friday, October 29, 2010 3:07 AM > To: Chris Engel > Cc: 'james woodyatt'; Roger Marquis; NAT66 HappyFunBall > Subject: Re: [nat66] e2e New Version Notification > > > > Le 28 oct. 2010 à 20:51, Chris Engel a écrit : > > > That's exactly the type of scenario most Enterprises DON'T > want to see > > work. In cases of INBOUND connections, Enterprises > generally WANT them > > to fail unless the Enterprise has taken explicit measures > to make them > > work. > > Can't FW's do that without needing address translation;? >
Yes they can. The point I'm making here is that NAT isn't doing much HARM to the Enterprise since it's not breaking anything they wouldn't want broken anyways. The functionality it provides in this context is to add an extra layer of partial protection in case the FW filter rules fail (i.e. someone misconfigured them). With IPV4 NAT none of the devices with MANY:1 mappings are able to recieve inbound connections even if the FW filters would allow it. Those sort of devices also tend to be the ones most likely to be easly exploitable if they did recieve such traffic. > > Furthermore, more often then not, when the Enterprise does > want them > > to work, it's going to FORCE said apps to go through some > well known, > > centrally managed point (i.e. some sort of Proxy/ALG) where > it can be > > monitored/audited/controlled and perhaps some policies > regarding how > > it is being used can be enforced. > > If some proxy is traversed, what is the use of NAT66? NAT tends to break such apps even if the FW rules let them pass. This can be true of OUTBOUND connections as well. For example, it's impractical to impose a DENY HTTP OUT ALL on most workstations simply due to the fact that alot of them will legitimately need web access. Yet it can be difficult for a filter to differentiate between legitimate web traffic and some P2P application encapsulating it's communications in HTTP to bypass FW filters. The filter has to be pretty sophisticated and do some deep packet inspection. Yet even if the filter lets traffic out...if the app is reporting an RFC 1918 address to it's peer...that ip isn't going to be particularly usefull for the peer.... and if the app tries to use some well known external intermediary to facilitate comminications....well you CAN black hole those...unlike some poor dial-up customers DHCP address. Thus NAT helps FORCE such apps to use ALG's setup by the Enterprise Admin in order to work successfully. Granted, it's not a complete solution, as many apps will find a way to work across the NAT boundary....and you are generaly better off trying to control such apps by imposing strict software policies on the individual workstations. However it DOES make it more difficult for Apps to work without some intervention on the Enterprise's part...and for many Enterprises anything that helps do that is a good thing. > > > > > > In other words, NAT generally isn't breaking anything that the > > Enterprise doesn't want broken anyway.... and *may* actually be > > helping to break certain things that would be somewhat more > difficult > > to break without it. > > Could you be more precise (asterisks added)? See above examples. > > > This is an area where Enterprises and Transit Providers seem to be > > entirely different animals with different priorities. > > Agreed, but questions about enterprise configurations that > really need NAT66 are still legitimate. Yes they are, but generaly the most informed opinions about that are going to be coming from people actually RUNNING enterprise configurations. Roger is not wrong when he claims that a very large majority of those ARE looking for NAT-like functionality. At least that's been my anecdotal experience from the most of the other people running Enterprises that I've talked to about it. > > > Let's look at something like VOIP. From the individual > consumers point > > of view the idea that you can sit down at any internet connection > > anywhere in the world and have a free/low cost voice > conversation with > > anyone at an internet connection anywhere else in the world is > > awesomely cool. However from the perspective of many > Enterprises this > > is very problematic for business related calls. Enterprises may > > require specific things happen in relation to business > calls (such as > > monitoring, auditing, recording) that are infinitely harder > to achieve > > unless such calls are FORCED to go through a central service. > > > > So for example, when customer calls up the company and > says... "One of > > your Operators called me up at 2 AM and promised me X". > The response > > from IT isn't.... > > > > "OK we'll try to search through every single workstation in the > > company, including those which are out for repairs, and see > If anyone > > was running Skype at 2 AM....and Oh god, I hope they were following > > policy and recording the call if they did....and Oh god, I hope > > someone didn't screw up and let a personal device plug into our > > network jacks." > > > > The response is.... > > > > "We have a record of every call originating from our network. > > Searching the call log db we can see that a call was placed to this > > number at 5:02 PM from Operator #231 at workstation 211 in > the Houston > > Branch. Here is the voice-recording of the content of that > call. Shall > > I play it for you so that you can hear exactly what was said?" > > That's clear. > But WHY would this require address translation? Doesn't REQUIRE it. But nothing about address translation harms such a usage case...and in some instances it MAY (see above examples) help insure it. > > Regards, > RD > > > 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
