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

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:brc(_at_)zurich(_dot_)ibm(_dot_)com] 
> Sent: Thursday, March 08, 2007 9:57 AM
> To: Hallam-Baker, Phillip
> Cc: Harald Tveit Alvestrand; ietf(_at_)ietf(_dot_)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:brc(_at_)zurich(_dot_)ibm(_dot_)com]
> > > Sent: Thursday, March 08, 2007 5:13 AM
> > > To: Hallam-Baker, Phillip
> > > Cc: Harald Tveit Alvestrand; ietf(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf