OK I will restate. All connection initiation should be exclusively mediated through the DNS and only the DNS. The reason I introduced the term signalling was precisely because setting up a connection today involves more than naming. Saying that the DNS should be the exclusive naming infrastructure is not a new position. What I am saying is that today session initiation involves more than the DNS and that this makes the IPv4/IPv6 transition more difficult than it should be. > -----Original Message----- > From: Harald Tveit Alvestrand [mailto:harald@xxxxxxxxxxxxx] > Sent: Wednesday, March 07, 2007 6:01 PM > To: Hallam-Baker, Phillip > Cc: ietf@xxxxxxxx > Subject: DNS role (RE: NATs as firewalls, cryptography, and > curbing DDoS threats.) > > Here I was thinking that the DNS needs to be an useful name > lookup service for the Internet to function, and now PHB > tells me it's a signalling layer. > > Either I have seriously misunderstood the nature of > "signalling", seriously misunderstood the nature of the DNS, > or I have reason to dislike this term. > > *shudder*. > > Harald > > --On 7. mars 2007 12:51 -0800 "Hallam-Baker, Phillip" > <pbaker@xxxxxxxxxxxx> > wrote: > > > 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@xxxxxxxxxxxxxx] > >> Sent: Wednesday, March 07, 2007 2:33 PM > >> To: John C Klensin > >> Cc: ietf@xxxxxxxx > >> 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@xxxxxxxx > >> https://www1.ietf.org/mailman/listinfo/ietf > >> > > > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/ietf > > > > > > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf