RE: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS thre

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(_at_)alvestrand(_dot_)no] 
> Sent: Wednesday, March 07, 2007 6:01 PM
> To: Hallam-Baker, Phillip
> Cc: ietf(_at_)ietf(_dot_)org
> 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(_at_)verisign(_dot_)com>
> 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(_at_)mail-abuse(_dot_)org]
> > > Sent: Wednesday, March 07, 2007 2:33 PM
> > > To: John C Klensin
> > > Cc: ietf(_at_)ietf(_dot_)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(_dot_)org
> > > https://www1.ietf.org/mailman/listinfo/ietf
> > _______________________________________________
> > Ietf mailing list
> > Ietf(_at_)ietf(_dot_)org
> > https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf