Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
On Mar 9, 2007, at 2:41 AM, Brian E Carpenter wrote: Phill, I'm not playing with words. The style of 'connection' involved in a SIP session with proxies is very different from that of a classical TCP session or a SOAP/HTTP/TCP session, or something using SCTP for some signalling purpose. And audio or video streaming over RTP is something else again. Java programmers that I know already open/close by DNS name without knowing whether IPv6 is in use. But that is the plain TCP style of session, underneath. There is a lot more than that in the network. Once IPv4 and IPv6 converge to a greater degree, going from point A to point B will represent a more complex journey. For DNS to better facilitate this transition, where encapsulation or tunneling techniques might be used, a greater amount of information could prove useful. Much of this information may help make the IPv4 journey transparent. The added complexity better navigates through this new landscape and might help Phillip obtain his goals of communicating between points A and B using multiple protocols and connections. IPv6 Aggregatable Global Unicast Address Format allows the IPv4 address to be embedded into the IPv6 header. Neighbor Discovery uses the 6to4 prefix in DNS. Teredo permits existing IPv4 NATs to forward traffic, rather than expecting a NAT to perform the IPv4 to IPv6 translation. Of course there is also the IPv6 to IPv4 relays, where the mapping might be dynamically assigned. Despite a widely held and perhaps altruistic view that network providers only need to be concerned about connectivity, in reality they also have the unprofitable and undesired task of excluding unwanted traffic. Altruism of Internet Openness must be tempered by network provider stewardship curbing unwanted traffic. Translations and much larger address space impinge upon this essential, albeit thankless task. Without this stewardship, the Internet will suffer from the bad behavior of a few, making the Internet unusable for everyone. Cryptography offers a solution, but only when also combined with a safe, lightweight means for authorizing the transmitter. The most practical means for bridging between these disparate worlds of IPv4 and IPv6 would be through the use of DNS validated names. In other words, Name X authorizes Name Y that has been validated using existing DNS records. An extensible means for implementing such name based authorization could be by name hash labels. The underlying reason for authorization is to prevent cryptographic signature replay abuse. Constraining bandwidth currently curtails much of the unwanted traffic while avoiding more draconian techniques. Phillip has considered this topic more broadly and is proposing a grander scheme. Working on a comprehensive and safe solution at this time makes a good deal of sense. As UDP will be carrying much of the traffic, where UDP itself is connectionless, the scope could be generalized at the packet. Of course no scheme would be efficient on a per packet basis. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
Phill,
I'm not playing with words. The style of 'connection' involved in a SIP session
with proxies is very different from that of a classical TCP session or a
SOAP/HTTP/TCP session, or something using SCTP for some signalling purpose.
And audio or video streaming over RTP is something else again.
Java programmers that I know already open/close by DNS name without
knowing whether IPv6 is in use. But that is the plain TCP style of
session, underneath. There is a lot more than that in the network.
Brian
On 2007-03-08 19:41, Hallam-Baker, Phillip wrote:
There is this protocol called TCP that runs over IP which provides the logical
connection.
Sniping at the use of vocabulary is not helpful here. You are refering to the
extant architecture and so the vocaulary precisely matches the concepts you
wish to refer to. I am proposing to make a few modest tweaks to the
architecture. While the tweaks I propose bring it closer to the original vision
of Cerf, Clark, Postel et al. I cannot explain it using the standard vocabulary.
My objective as an application designer is precisely to get to the point where
the application running on top of the Internet stack can exist in blisfull
ignorance of what is going on at the lower layers.
OK lets try code, at the moment to start up a TCP socket you have code of the
form:
struct sockaddr_in local, mask;
SOCKET s;
local.sin_port = htons (port);
local.sin_family= AF_INET;
local.sin_addr.s_addr = inet_addr(address);
// Create a socket
s = socket (AF_INET, SOCK_STREAM, 0);
Assert (s != INVALID_SOCKET, -1, ("Could not allocate socket"));
// Bind the socket to the TCP interface and port
int b = bind(s, (struct sockaddr*)&local, sizeof(local));
Assert (b != SOCKET_ERROR, -1, ("Could not bind to socket"));
The application should not be dealling with any of this. The IP address should
never be exposed to the application in any form. Same goes for the protocol.
It should be possible to define an API call of the form (again using a C idiom
although one would hope to use C# or Java):
s = serve ( dns_name, service_name, profile )
s = connect ( dns_name, service_name, profile )
Where profile contains information that describes the service (protocol options,
versions supported &ct.) on the serve call and those desired on the connect
call. (alternatively implement via a callback structure or split connect into a
resolution and connection phases)
I don't think that the application should know anything about the details of the IP level, not the port and certainly not the address.
It should be possible to implement the serve and connect API using only the information in the DNS combined with a static table of information relating to legacy protocols that use the well known port scheme.
It might be advantageous for the platform to decide to supplement that
information with additional sources but that should not be visible at the
application layer.
I think that this architecture is a lot more disciplined than what we have
today. It observes the encapsulation property / layering principle much better.
-Original Message-
From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 08, 2007 9:57 AM
To: Hallam-Baker, Phillip
Cc: Harald Tveit Alvestrand; ietf@ietf.org
Subject: Re: DNS role (RE: NATs as firewalls, cryptography,
and curbing DDoS threats.)
Ah. Well I always learnt that an IP network was a
connectionless network. Maybe you'd like to define what you
mean by a connection.
Brian
On 2007-03-08 14:42, Hallam-Baker, Phillip wrote:
DHCP: of course not, its routing address acquisition, not
connection
initiation Default Gateway: Again no connection.
DNS server: of course, it’s a tautology that interactions
with the DNS are mediated by the DNS, but again its not
connection initiation.
The most complicated case here is SLP. The primary problem
in SLP is that it has failed to establish a sufficiently
diverse adoption community. There are four competing
protocols in the space, few signs of life in any of them.
The secondary problem in SLP is that it appears to be
grounded in the conception of the local network being the
locally contiguous network. Using multicast is in theory more
scalable than Ethernet broadcast and could take the scheme
beyond the SOHO network. In practice you have to believe in
Tinkerbell. I don't.
Since I can do everything that SLP does using the pure DNS
and an announcement service that is my preferred option. If
SLP was ubiquitously supported it would be a different matter.
Getting three out of four camps to admit that their
proposal is not likely to make it and converge on the fourth
is likely to be very difficult and the spec that wins is
probably not going to do so on technical merit. Again, its
five years since this was all promised to the consumer.
Grafting the s
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
On Thu, Mar 08, 2007 at 10:41:02AM -0800, Hallam-Baker, Phillip <[EMAIL PROTECTED]> wrote a message of 115 lines which said: > OK lets try code, at the moment to start up a TCP socket you have > code of the form: In C. In every other language I know, it is at a much higher level. (Even in C, programmers often use something like libcurl or neon, which frees them of these awful details. My personal rant, in french only, is at http://www.bortzmeyer.org/network-high-level-programming.html.) > The application should not be dealling with any of this. The IP > address should never be exposed to the application in any form. Same > goes for the protocol. Do you really mean "the application" (and, in that case, we are already there) or "the userland" (and this is a more complicated problem). And do you mean "the application should not HAVE TO know these details" (and we agree and it is already possible) or "the application MUST NOT be able to know these details, they should be kept in the kernel" (which would be a much stronger statement). > I don't think that the application should know anything about the > details of the IP level, not the port and certainly not the address. If I understand the idea you have been developed in this thread, it seems close from a Locator / Identifier split with DNS names as the Identifier. Am I wrong? Do note that the "original" paper about endpoints (Endpoints and Endpoint Names: A Proposed Enhancement to the Internet Architecture) mentioned that: 10.4 Domain Name System (DNS) Names An obvious, ready-made, namespace for endpoint are DNS names. These have the advantage of being an existing system, with an allocation system all worked out. Among other advantages of DNS names, since they are variable length, and composed of a variable number of levels, there is no danger of running out of them, and new ones can be allocated locally by appending some locally unique identifier to the DNS name of the entity creating the new endpoint name. They would probably not be suitable for inclusion in each packet, of course, at least not directly; this would limit their ability to be used as demultiplexors. However, an additional ESEL field in the packets would provide this capability; the full DNS-type endpoint name would still be used both at the time the connection is set up, and in the end-end checksum pseudo-header. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
There is this protocol called TCP that runs over IP which provides the logical
connection.
Sniping at the use of vocabulary is not helpful here. You are refering to the
extant architecture and so the vocaulary precisely matches the concepts you
wish to refer to. I am proposing to make a few modest tweaks to the
architecture. While the tweaks I propose bring it closer to the original vision
of Cerf, Clark, Postel et al. I cannot explain it using the standard vocabulary.
My objective as an application designer is precisely to get to the point where
the application running on top of the Internet stack can exist in blisfull
ignorance of what is going on at the lower layers.
OK lets try code, at the moment to start up a TCP socket you have code of the
form:
struct sockaddr_in local, mask;
SOCKET s;
local.sin_port = htons (port);
local.sin_family= AF_INET;
local.sin_addr.s_addr = inet_addr(address);
// Create a socket
s = socket (AF_INET, SOCK_STREAM, 0);
Assert (s != INVALID_SOCKET, -1, ("Could not allocate socket"));
// Bind the socket to the TCP interface and port
int b = bind(s, (struct sockaddr*)&local, sizeof(local));
Assert (b != SOCKET_ERROR, -1, ("Could not bind to socket"));
The application should not be dealling with any of this. The IP address should
never be exposed to the application in any form. Same goes for the protocol.
It should be possible to define an API call of the form (again using a C idiom
although one would hope to use C# or Java):
s = serve ( dns_name, service_name, profile )
s = connect ( dns_name, service_name, profile )
Where profile contains information that describes the service (protocol
options, versions supported &ct.) on the serve call and those desired on the
connect call. (alternatively implement via a callback structure or split
connect into a resolution and connection phases)
I don't think that the application should know anything about the details of
the IP level, not the port and certainly not the address.
It should be possible to implement the serve and connect API using only the
information in the DNS combined with a static table of information relating to
legacy protocols that use the well known port scheme.
It might be advantageous for the platform to decide to supplement that
information with additional sources but that should not be visible at the
application layer.
I think that this architecture is a lot more disciplined than what we have
today. It observes the encapsulation property / layering principle much better.
> -Original Message-
> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 08, 2007 9:57 AM
> To: Hallam-Baker, Phillip
> Cc: Harald Tveit Alvestrand; ietf@ietf.org
> Subject: Re: DNS role (RE: NATs as firewalls, cryptography,
> and curbing DDoS threats.)
>
> Ah. Well I always learnt that an IP network was a
> connectionless network. Maybe you'd like to define what you
> mean by a connection.
>
> Brian
>
> On 2007-03-08 14:42, Hallam-Baker, Phillip wrote:
> > DHCP: of course not, its routing address acquisition, not
> connection
> > initiation Default Gateway: Again no connection.
> >
> > DNS server: of course, it’s a tautology that interactions
> with the DNS are mediated by the DNS, but again its not
> connection initiation.
> >
> >
> > The most complicated case here is SLP. The primary problem
> in SLP is that it has failed to establish a sufficiently
> diverse adoption community. There are four competing
> protocols in the space, few signs of life in any of them.
> >
> > The secondary problem in SLP is that it appears to be
> grounded in the conception of the local network being the
> locally contiguous network. Using multicast is in theory more
> scalable than Ethernet broadcast and could take the scheme
> beyond the SOHO network. In practice you have to believe in
> Tinkerbell. I don't.
> >
> >
> > Since I can do everything that SLP does using the pure DNS
> and an announcement service that is my preferred option. If
> SLP was ubiquitously supported it would be a different matter.
> >
> > Getting three out of four camps to admit that their
> proposal is not likely to make it and converge on the fourth
> is likely to be very difficult and the spec that wins is
> probably not going to do so on technical merit. Again, its
> five years since this was all promised to the consumer.
> >
> > Grafting the schemas developed onto an existing
> infrastructure everyone already agrees on is probably an
> easier prospect politically.
> >
> >
> >> -Original Message-
> >> From: Brian E Carpenter [mailto:[EMAIL PROTECTED]
> >
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
Harald Tveit Alvestrand wrote: In my opinion, we should never introduce any function that involves the DNS where: - the answer is required to be different for different requestors - the answer has to be different at two times separated by less than ~seconds - a temporary failure of the resolution process is a fatal error rather than a delay These strike me as some really excellent, basic requirements, for any DNS usage. Offhand, I don't see why the second bullet isn't stronger. Althought there are many scenarios in which the producer of DNS responses might choose to make responses be different over time (or for that matter, different for different requestors) I see these as local implementation choices, rather than being built into the definition of the standardized service. Hence, I do not see why the answer *ever* "has to be" different. That said, I suppose we could use Postelian language, of the style "until something changes", where a machine's getting a new IP Address is an obvious example. Since the terms "mediated" and "signalling", in the way I commonly use them, violates the first of these points in almost every design I'm aware of, I think those are lousy terms to use for any function that the DNS is good for. 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. I did not initially see why the term "signalling" might be causing heartburn, with respect to the DNS. But the (entirely reasonable) view that "signaling" means "an exchange of control information among participants as part of the establishment of an association, then no, the DNS does not qualify. By way of example, having TCP use domain names would make the DNS be part of the signaling mechanism, I think. But it's current role is carefully kept separate from that. (Multi-addressing designs that use domain names might therefore be viewed as making the DNS be part of a signaling mechanism, which of course explains why so many IETF infrastructure folk have had heartburn about that dependency.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
On Mar 8, 2007, at 2:13 AM, Brian E Carpenter wrote: On 2007-03-08 02:06, Hallam-Baker, Phillip wrote: OK I will restate. All connection initiation should be exclusively mediated through the DNS and only the DNS. Would that include connections to one's DHCP server, SLP server, default gateway, and DNS server? Hmm... This is represents a controversial topic where my perspective might be somewhat unique. But... In systems that are attempting to be as open as possible, where email is an example, the primary method for controlling abuse has been to truncate connections based upon IPv4 addresses. This address space allows methods using a deterministic amount of solid state resources. When that address space become complex, where sources represent a series of addresses translated by gateways, or even using an IPv6 address, tracking soon exceeds practical resource provisioning. The quality of the control depends upon rapid turn-around by reacting from solid state resources. The alternatives are many orders of magnitude slower. It is not just the route, which is part of the assessment, but also the specific point of origin being tracked. There are techniques to consolidate the address space, but this is not an ideal solution. Use of IPv4 addressing as a means to control abuse will soon become problematic. One approach would be to identify the client by name, and then allow merged messages be cryptographically identified by name, where this name then authorizes the specific client by name. A weakness of cryptographic identification is that it can be replayed. While there might be rate limits in place initially, message replay thwarts reliance on solely the cryptographic identification. By relying upon the stewardship of the client responding promptly to reports of abuse, tracking the names of the clients permits the use of any IP addressing scheme. The cryptographic identifier would authorize the client, or the message would be slowed using various techniques to impose a type of receiver side rate limiting, that might otherwise be lacking. Rate limiting affords time to respond and limits the level of damage. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
On 8-Mar-2007, at 10:17, Arnt Gulbrandsen wrote: A prediction: Sooner or later, IPv4 addresses become so scarce that renting a colo server with IPv4 becomes more expensive than IPv6. When that happens, a few NAT-hating spoilsports will set up the first few IPv6-only servers and a year later, the transition to IPv6 starts. I wonder what kind of server that'll be - game servers, perhaps? Torrents and porn. Possibly torrents of porn. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
A prediction: Sooner or later, IPv4 addresses become so scarce that renting a colo server with IPv4 becomes more expensive than IPv6. When that happens, a few NAT-hating spoilsports will set up the first few IPv6-only servers and a year later, the transition to IPv6 starts. I wonder what kind of server that'll be - game servers, perhaps? Arnt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
Ah. Well I always learnt that an IP network was a connectionless network. Maybe you'd like to define what you mean by a connection. Brian On 2007-03-08 14:42, Hallam-Baker, Phillip wrote: DHCP: of course not, its routing address acquisition, not connection initiation Default Gateway: Again no connection. DNS server: of course, it’s a tautology that interactions with the DNS are mediated by the DNS, but again its not connection initiation. The most complicated case here is SLP. The primary problem in SLP is that it has failed to establish a sufficiently diverse adoption community. There are four competing protocols in the space, few signs of life in any of them. The secondary problem in SLP is that it appears to be grounded in the conception of the local network being the locally contiguous network. Using multicast is in theory more scalable than Ethernet broadcast and could take the scheme beyond the SOHO network. In practice you have to believe in Tinkerbell. I don't. Since I can do everything that SLP does using the pure DNS and an announcement service that is my preferred option. If SLP was ubiquitously supported it would be a different matter. Getting three out of four camps to admit that their proposal is not likely to make it and converge on the fourth is likely to be very difficult and the spec that wins is probably not going to do so on technical merit. Again, its five years since this was all promised to the consumer. Grafting the schemas developed onto an existing infrastructure everyone already agrees on is probably an easier prospect politically. -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Thursday, March 08, 2007 5:13 AM To: Hallam-Baker, Phillip Cc: Harald Tveit Alvestrand; ietf@ietf.org Subject: Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.) On 2007-03-08 02:06, Hallam-Baker, Phillip wrote: OK I will restate. All connection initiation should be exclusively mediated through the DNS and only the DNS. Would that include connections to one's DHCP server, SLP server, default gateway, and DNS server? Hmm... Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
DHCP: of course not, its routing address acquisition, not connection initiation Default Gateway: Again no connection. DNS server: of course, it’s a tautology that interactions with the DNS are mediated by the DNS, but again its not connection initiation. The most complicated case here is SLP. The primary problem in SLP is that it has failed to establish a sufficiently diverse adoption community. There are four competing protocols in the space, few signs of life in any of them. The secondary problem in SLP is that it appears to be grounded in the conception of the local network being the locally contiguous network. Using multicast is in theory more scalable than Ethernet broadcast and could take the scheme beyond the SOHO network. In practice you have to believe in Tinkerbell. I don't. Since I can do everything that SLP does using the pure DNS and an announcement service that is my preferred option. If SLP was ubiquitously supported it would be a different matter. Getting three out of four camps to admit that their proposal is not likely to make it and converge on the fourth is likely to be very difficult and the spec that wins is probably not going to do so on technical merit. Again, its five years since this was all promised to the consumer. Grafting the schemas developed onto an existing infrastructure everyone already agrees on is probably an easier prospect politically. > -Original Message- > From: Brian E Carpenter [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 08, 2007 5:13 AM > To: Hallam-Baker, Phillip > Cc: Harald Tveit Alvestrand; ietf@ietf.org > Subject: Re: DNS role (RE: NATs as firewalls, cryptography, > and curbing DDoS threats.) > > On 2007-03-08 02:06, Hallam-Baker, Phillip wrote: > > OK I will restate. > > > > All connection initiation should be exclusively mediated > through the DNS and only the DNS. > > > > Would that include connections to one's DHCP server, SLP > server, default gateway, and DNS server? > > Hmm... > > Brian > ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
> One approach for "name" based authorization would place an encoded > hash label of the domain name being authorized within the > authorizing > domain. Client validation can be as simple as resolving the name of > the client, where this name can then be utilized in conjunction with > a "name" based authorization. In the case of DKIM, DNS also > supplies > the public key as well. Is there a draft describing this somewhere? --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
On 2007-03-08 02:06, Hallam-Baker, Phillip wrote: OK I will restate. All connection initiation should be exclusively mediated through the DNS and only the DNS. Would that include connections to one's DHCP server, SLP server, default gateway, and DNS server? Hmm... Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
--On 7. mars 2007 17:06 -0800 "Hallam-Baker, Phillip" <[EMAIL PROTECTED]> wrote: OK I will restate. All connection initiation should be exclusively mediated through the DNS and only the DNS. OK, I'll restate too. In my opinion, we should never introduce any function that involves the DNS where: - the answer is required to be different for different requestors - the answer has to be different at two times separated by less than ~seconds - a temporary failure of the resolution process is a fatal error rather than a delay Since the terms "mediated" and "signalling", in the way I commonly use them, violates the first of these points in almost every design I'm aware of, I think those are lousy terms to use for any function that the DNS is good for. 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. If you say "the initiator of a connection can use the DNS to look up information about the respondent before making the connection attempt, the lookup process can be more complex than an A-record lookup, and that information can be more complex than an IP address", I can agree with you wholeheartedly. If you say that "the respondent to a connection attempt can use the DNS to look up information about the initiator, based either on the initiator's IP address or on names the initiator includes in the connection attempt", I can agree that this is technically possible, but am worried about the number of devils in those details - as evidenced by the challenges of PTR lookup, SPF verification and so on. See also the 3rd bullet above. But I have trouble relating those two points of agreement with the words "mediated" and "signalling", using any of the definitions of those words that I can think of offhand. You may have a different dictionary than me. If so, please quote. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
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:[EMAIL PROTECTED] > Sent: Wednesday, March 07, 2007 6:01 PM > To: Hallam-Baker, Phillip > Cc: ietf@ietf.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" > <[EMAIL PROTECTED]> > 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:[EMAIL PROTECTED] > >> Sent: Wednesday, March 07, 2007 2:33 PM > >> To: John C Klensin > >> Cc: ietf@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 > >> > >> ___
Re: DNS role (RE: NATs as firewalls, cryptography, and curbing DDoS threats.)
On Mar 7, 2007, at 3:00 PM, Harald Tveit Alvestrand wrote: 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*. Perhaps signaling over simplifies the suggestion, and perhaps Philip sees this differently as well. Once IPv4 does not offer an identifier for defending against DoS attack, a safe basis could be established with a two step approach using DNS. Verify clients by "name" with a single DNS transaction. This offers a safe identifier that avoids DoS concerns. These identifiers can be subsequently authorized by "name" as well. DNS is well suited to resolve a small answer by name. One approach for "name" based authorization would place an encoded hash label of the domain name being authorized within the authorizing domain. Client validation can be as simple as resolving the name of the client, where this name can then be utilized in conjunction with a "name" based authorization. In the case of DKIM, DNS also supplies the public key as well. The concern was to avoid the indirect or reflected attacks DNS can produce, where a simple strategy can avoid these problems. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
