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