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

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 Mar 2007 17:06:07 -0800

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-masked]] 
> Sent: Wednesday, March 07, 2007 6:01 PM
> To: Hallam-Baker, Phillip
> Cc: [email-masked]
> 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-masked]>
> 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-masked]]
> >> Sent: Wednesday, March 07, 2007 2:33 PM
> >> To: John C Klensin
> >> Cc: [email-masked]
> >> 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
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/ietf
> >>
> >
> > _______________________________________________
> > Ietf mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ietf
> >
> 
> 
> 
> 
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 08 Mar 2007 07:32:11 +0100

> All connection initiation should be exclusively mediated through 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Mar 2007 11:13:07 +0100

> 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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Mar 2007 05:42:06 -0800

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.

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Thursday, March 08, 2007 5:13 AM
> Cc: Harald Tveit Alvestrand; [email-masked]
> Subject: Re: DNS role (RE: NATs as firewalls, cryptography, 
> and curbing DDoS threats.)
> 
> Would that include connections to one's DHCP server, SLP 
> server, default gateway, and DNS server?
> 
> Hmm...
> 
>      Brian
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Mar 2007 15:56:53 +0100

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 8 Mar 2007 16:17:28 +0100

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

---

From: Joe Abley <[email-masked]>
Date: Thu, 8 Mar 2007 10:47:10 -0500

On 8-Mar-2007, at 10:17, Arnt Gulbrandsen wrote:

> 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.
>

Torrents and porn. Possibly torrents of porn.

Joe

---

From: Douglas Otis <[email-masked]>
Date: Thu, 8 Mar 2007 08:24:35 -0800

On Mar 8, 2007, at 2:13 AM, Brian E Carpenter wrote:

>> OK I will restate. All connection initiation should be exclusively  
>> mediated through the DNS and only the DNS.
>

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 08 Mar 2007 09:10:10 -0800

Harald Tveit Alvestrand wrote:
> In my opinion, we should never introduce any function that involves the 
> DNS where:
> 

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.

> 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.
> 

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

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 8 Mar 2007 10:41:02 -0800

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.

> Sent: Thursday, March 08, 2007 9:57 AM
> 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
> 
> > 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.
> > 
> > 
> >> Subject: Re: DNS role (RE: NATs as firewalls, cryptography, and 
> >> curbing DDoS threats.)
> >>
> >> Would that include connections to one's DHCP server, SLP server, 
> >> default gateway, and DNS server?
> >>
> >> Hmm...
> >>
> >>      Brian
> >>
> > 
> 
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 9 Mar 2007 10:19:21 +0100

On Thu, Mar 08, 2007 at 10:41:02AM -0800,
 Hallam-Baker, Phillip <[email-masked]> wrote 

> OK lets try code, at the moment to start up a TCP socket you have

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Mar 2007 11:41:42 +0100

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 9 Mar 2007 11:44:40 -0800

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.
>

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