Re: [tae] New draft: announcing the supported transports via DNS

["Dan Wing" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Joe Touch
> Sent: Monday, October 05, 2009 6:28 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [tae] New draft: announcing the supported 
> transports via DNS
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 
> Andrew Yourtchenko wrote:
> > 
> > 
> > On Fri, 2 Oct 2009, Joe Touch wrote:
> > 
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Some comments below...
> >>
> >> Andrew Yourtchenko wrote:
> >> ...
> >>> Also, if we assume "evil middlebox" in the middle, that 
> decides to drop
> >>> this new option, we will have a TCP connection that would 
> not succeed,
> >>> so then still there needs to be a fallback to "plain TCP".
> >>>
> >>> That's one of the rationales of bringing up the use of 
> DNS in lieu of a
> >>> in-band selection in general - we would still need to be able to
> >>> fallback to probing in the worst case (how frequent is 
> the worst case
> >>> would of course need some more investigation).
> >>
> >> Use of the DNS is problematic on many levels:
> >>
> >> - - many users have IP addresses they don't control, e.g., 
> assigned by an
> >> ISP, and those ISPs don't offer the ability to register 
> services with
> >> their DNS
> > 
> > Use one of the dynamic DNS services. They exist and work 
> well for the
> > dynamic addresses. The ISP who assigns the IP has not much 
> to do with
> > the forward DNS resolution.
> 
> There are numerous applications that use reverse DNS for verification,
> e.g., HTTP name-based access, SSL, etc. Users don't have control over
> reverse DNS.

Agreed.

But how is reverse DNS authentication relevant to selection of 
a transport protocol?

> >> - - you're involving a third party in a two-party problem
> > 
> > It's not a two-party problem - at a minimum because the 
> policy/protocol
> > support on the nodes inbetween will influence the odds of 
> being able to
> > run a new transport.
> 
> Endpoints determine the meaning of a protocol. I can format messages
> that look like UDP, and have the endpoints parse them as TCP if I want
> - -- e.g., by having the endpoints interpret the transport protocol
> numbers accordingly. Intermediate points can think they know what's
> going on, and either try to help, block, or whatever, but they can be
> fooled.
> 
> I'm also considering other issues - first-contact delay, fault
> tolerance, etc. Involving a DNS node on the other side of the 
> planet in
> a shakey ISP might not be in the best interest of the two 
> endpoints of a connection.

draft-wood-tae-specifying-uri-transports meets those 
requirements, at least as I understand what you have
described in this email.

> >> - - you still have a bootstrapping problem -- by what 
> transport do you
> >> talk to the DNS?
> > 
> > I already know the addresses of the DNS servers. I know the default
> > transport will work. 
> 
> Why? Why should DNS have a default transport?
>
> I know my hosts's domain. Hence I can resolve the
> > hostnames of my DNS servers. Hence I can lookup the 
> transport record,
> > and see if they offer something more, that I could try - 
> keeping in mind
> > that it is a suggestion and not an imperative. If it does not work I
> > fall back onto using the default transport.
> 
> Hmm. So you can try a default to the DNS, and ask *it* for other
> suggestions if it supports them.
> 
> Why isn't this good enough for the two endpoints as well?
> 
> >>     - if you solve that for DNS, why not use that solution at the
> >>     endpoint?
> >>
> > 
> > See above. It works, because the lowest common denominator is always
> > available. So the DNS can work both for the "upgrade" of 
> the DNS and on
> > the endpoints for the suggestions about the new transports.
> 
> First, the DNS is not always available or desirable.
> 
> Second, if you solve this for the DNS, you can use a similar solution
> directly between the endpoints without involving the DNS.
>
> Third, if you force all endpoints to support a default 
> transport to talk
> to the DNS, you have a default transport to talk to all other 
> endpoints anyway.

I sure would like to see your straw man proposal, because I
cannot fathom how you would accomplish this feat.

-d


> ...
> >> It sounds like you've talked yourself out of using the 
> DNS, or mostly
> >> so. Is that the case?
> > 
> > No. What I am saying is that there is a place for both approaches.
> > 
> > In any case, would be interesting to know what constructive 
> suggestions
> > would you have on this topic ?
> > 
> > TCP option "let's kickstart a negotiation for a different 
> protocol" ?
> 
> How about a SYN for a new protocol that has room for negotiating other
> transports? (I see no need - or, as importantly, room, for doing this
> inside TCP SYN option space).
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> 
> iEYEARECAAYFAkrJ9HgACgkQE5f5cImnZrvZkgCfcpAWc0DT/uRyvZ/Db51Cn77b
> aLcAoO6kLdO8LAPrwynC47OJGIa9siCY
> =cKDO
> -----END PGP SIGNATURE-----
> _______________________________________________
> tae mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tae
>