RE: NATs as firewalls, cryptography, and curbing DDoS threats.

["Hallam-Baker, Phillip" <pbaker at verisign.com>]

Doug makes a critical point here:

In order to successfully make a technology transition at the IP layer we have to change the way in which we use the DNS layer.

Another way to look at the routing problems exposed by NAT is that they are the result of relying on the IP layer for signalling rather than the DNS.

I fully agree with John's desire for a coherent Internet architecture. If we want to successfully make the transition from IPv4 to IPv6 we have to consider the DNS as the end-to-end signalling infrastructure rather than viewing this as being shared between the DNS and the IP layer beneath it.



> -----Original Message-----
> From: Douglas Otis [mailto:dotis at mail-abuse.org] 
> Sent: Wednesday, March 07, 2007 2:33 PM
> To: John C Klensin
> Cc: ietf at ietf.org
> Subject: Re: NATs as firewalls, cryptography, and curbing 
> DDoS threats.
> 
> 
> On Mar 7, 2007, at 9:01 AM, John C Klensin wrote:
> 
> > It is true that I tend to be pessimistic about changes to deployed 
> > applications that can't be "sold" in terms of clear value.  
> I'm also 
> > negative about changing the architecture to accommodate short- term 
> > problems.  As examples of the latter, I've been resistant 
> to changing 
> > (distinguished from adding more features and capability
> > to) the fundamentals of how email has worked for 30+ years 
> in order to 
> > gain short-term advantages against spammers.
> 
> There will be growing concerns related to abuse when ISPs 
> deploy IPv6 internally and then use IPv4 gateways to gain 
> "full" access to the Internet.  Any changes related to 
> controlling abuse should be aimed at identifying entities 
> controlling transmission.  Resolving the address using a 
> domain name at least identifies the administrative entity From ietf-bounces at ietf.org Wed Mar 07 17:51:27 2007
Return-path: <ietf-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HP4sV-0000wA-Dr; Wed, 07 Mar 2007 17:44:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HP36y-0003qp-AR
	for ietf at ietf.org; Wed, 07 Mar 2007 15:51:48 -0500
Received: from colibri.verisign.com ([65.205.251.74])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HP36p-0001oN-Hv
	for ietf at ietf.org; Wed, 07 Mar 2007 15:51:48 -0500
Received: from mou1wnexcn01.vcorp.ad.vrsn.com (mailer1.verisign.com
	[65.205.251.34])
	by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l27KpY7p016971;
	Wed, 7 Mar 2007 12:51:34 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by
	mou1wnexcn01.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 7 Mar 2007 12:51:33 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 7 Mar 2007 12:51:30 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD3701147CA8 at MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: NATs as firewalls, cryptography, and curbing DDoS threats.
Thread-Index: Acdg75qgXuYFybLSR9CLhkAFqs8TKwACcSYw
From: "Hallam-Baker, Phillip" <pbaker at verisign.com>
To: "Douglas Otis" <dotis at mail-abuse.org>, "John C Klensin" <john-ietf at jck.com>
X-OriginalArrivalTime: 07 Mar 2007 20:51:33.0487 (UTC)
	FILETIME=[63BE87F0:01C760FA]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1
Cc: ietf at ietf.org
Subject: RE: NATs as firewalls, cryptography, and curbing DDoS threats.
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org

Doug makes a critical point here:

In order to successfully make a technology transition at the IP layer we have to change the way in which we use the DNS layer.

Another way to look at the routing problems exposed by NAT is that they are the result of relying on the IP layer for signalling rather than the DNS.

I fully agree with John's desire for a coherent Internet architecture. If we want to successfully make the transition from IPv4 to IPv6 we have to consider the DNS as the end-to-end signalling infrastructure rather than viewing this as being shared between the DNS and the IP layer beneath it.



> -----Original Message-----
> From: Douglas Otis [mailto:dotis at mail-abuse.org] 
> Sent: Wednesday, March 07, 2007 2:33 PM
> To: John C Klensin
> Cc: ietf at ietf.org
> Subject: Re: NATs as firewalls, cryptography, and curbing 
> DDoS threats.
> 
> 
> On Mar 7, 2007, at 9:01 AM, John C Klensin wrote:
> 
> > It is true that I tend to be pessimistic about changes to deployed 
> > applications that can't be "sold" in terms of clear value.  
> I'm also 
> > negative about changing the architecture to accommodate short- term 
> > problems.  As examples of the latter, I've been resistant 
> to changing 
> > (distinguished from adding more features and capability
> > to) the fundamentals of how email has worked for 30+ years 
> in order to 
> > gain short-term advantages against spammers.
> 
> There will be growing concerns related to abuse when ISPs 
> deploy IPv6 internally and then use IPv4 gateways to gain 
> "full" access to the Internet.  Any changes related to 
> controlling abuse should be aimed at identifying entities 
> controlling transmission.  Resolving the address using a 
> domain name at least identifies the administrative entity of 
> the client.  For example, multimedia streaming has been 
> fraught with security exploits.
> 
> As traffic merges into common channels, there will be a 
> desire to minimize cryptographic identifier abuse, in 
> particular for things like DKIM.  While there exists an 
> experimental method for a domain to "authorize" a client, 
> this technique represents a significant hazard.  This hazard 
> is created by the iterative construction of address lists and 
> the macro expansion of local-part components of a 
> email-address.  The inherent capability of this method 
> permits a sizable attack to be stage without expending 
> additional resources of the attacker.  In addition, this 
> experimental scheme fails to identify the point of 
> transmission staging the attack.
> 
> Those offering outbound services desire that acceptance be 
> based upon their customer's reputation rather than upon that 
> of their stewardship.  With the experimental scheme, the 
> administrative entity for the client is not relevant, 
> although essential when guarding against abuse.  There are 
> several orders of magnitude more customers than outbound 
> service providers.  Guarding against abuse must depend upon a 
> means to consolidate the entities being assessed.
> 
> There are millions of new domains generated every day at no 
> cost to the bad actors.  When IPv6 becomes more common, the 
> IP address may even exceed a scalable defensive.  The long 
> standing practice allowing clients to remain nameless will 
> need to change.  For SMTP, the EHLO should resolve.  Any 
> authorization scheme should then be based upon a name lookup 
> and not upon a list of IP addresses for thousands of transmitters.
> 
> -Doug
> 
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf