DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf






_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]