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

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