Diego, > Hi Michael, > > On 9 Nov 2012, at 20:53 , Scharf, Michael (Michael) wrote: > > U-NAPTR application service tags are registered with IANA, > and that is what the current ALTO discovery draft does. > > > > I wonder how and where ALTO would register its URI if it > were using draft-jones-simple-web-discovery for discovery. > Probably in new IANA registry? > > > > Such questions would probably have to be sorted out > elsewhere in the IETF before ALTO discovery could rely on > draft-jones-simple-web-discovery. > > Hmmm, I think you have a point here. But I'll investigate > whether there is a URN namespace associated with DNS names, > so an URI built according to current registration could be > directly used.
My main point is that this has to be sorted out e. g. in APPAREA before we can rely on an RFC in that space. It is unclear to me whether draft-jones-simple-web-discovery will be a mature and widely used technique any time soon. > > I don't really understand your argument regarding the > client. The ALTO client has to perform DNS queries anyway, i. > e., DNS is not a new protocol on the client side. > > Indeed, but my take is that the client relies on DNS in an > indirect way, by requesting HTTP(S) connections that use DNS > to parse the URL, but not directly accessing the DNS > interface. Therefore, using HTTP(S) again would be the most > natural way to perform discovery. Sure, a HTTP(S) discovery mechanisms has benefits in a Web world. But DNS also has benefits. There is an engineering tradeoff. Thus, I disagree that HTTP(S) is the "most natural way". > > However, my impression is that > draft-jones-simple-web-discovery could result in quite some > complexity on the server side. My understanding of the > proposal is that, if applied to ALTO, an access network > provider would have to run a Web server for each access > network domain names announced in the DHCP option according > to RFC 5986. I could imagine that this results in quite some > operational issues for an ISP: > > > > - Today, an operator might not run Web servers for domain > names such as "dsl.westcoast.myisp.net", i. e., this might > require a new server infrastructure. Compared to that, the > DNS infrastructure already exists and just has to be extended > by entries. > > Deploying virtual Web servers is a rather trivial task (in a > typical Apache setup, we are talking about adding a few lines > to configuration files), and you need Web servers anyway to > run the ALTO base protocol My concern is that RFC 5986 announces an access network domain name, such as "dsl.westcoast.myisp.net". In my understanding, draft-jones-simple-web-discovery requires that a Web server is running at https://sl.westcoast.myisp.net/.well-known/simple-web-discovery . Furthermore, unless I miss something, there is no need for an DNS entry that maps "dsl.westcoast.myisp.net" to specific host right now. Thus, for draft-jones-simple-web-discovery to work with RFC 5986, an ISP might have to add new DNS entries for each access network domain name, pointing to a Web server, that then figures out the closest ALTO server URI. With U-NAPTR, the DNS server just gives the closest ALTO server URI directly. In summary: - Both variants are likely to require new DNS entries - draft-jones-simple-web-discovery requires one more indirection, i. e., one more system to configure, and one more system that has to be aware of the network topology to figure out the closest ALTO server, etc. Obviously, an alternative would be to specify a new DHCP option that directly announces the URI of the SWD Web Server. That is not very different to a DHCP option that just encodes the ALTO server URI. This is all doable, at least in principle. But the approach of encoding URIs in DHCP got pretty strong pushback in previous ALTO meetings, as far as I recall. > > - There may be synchronization issues, e. g. in case of > domain mame renumbering, because different databases have to > be kept in sync. Right now, for ALTO discovery to work well, > an ISP may have to keep DHCP and DNS in sync, which are both > well-established network services. With > draft-jones-simple-web-discovery, a third Web infrastructure > has to be taken into account. > > Again, this maintenance is straightforward, since it is > related to dealing with virtual servers in any modern Web > server framework. It is more a matter of which branch in an > organization has access to DHCP, DNS, and Web servers for > infratsructural matters. My point is that DNS is usually the > most hard to change, due to it being a critical service for > many others. My point is that ALTO server discovery has to figure out what server can provide guidance for a specific access network, taking into account renumbering, domain name migrations, etc. I am not sure if the organizational unit of an ISP that runs the Web platform really has a better understanding of the access network topology and naming than the organization unit that runs DNS and DHCP. I'd assume the opposite. Sure, it is up to an ISP to sort this out. > > - I could imagine that load balancing mechanisms and > strategies for DNS could be quite different from Web load > balancing, also taking into account HTTP proxies etc. ALTO > discovery requires that a topologically close server is > discovered. The DNS infrastructure is a network service and > thus somehow linked to topology, unlike a Web platform. > > Sorry, I do not follow your reasoning here. Will not that > imply that the whole ALTO infrastructure would be better > suited for running on DNS? No. The sole purpose for the discovery is to find the URI of a suitable ALTO server. For instance, I am concerned about a scenario where a transparent HTTP proxy is deployed inside the access network. For instance, assume that all client traffic on port 80 and 443 is forced through a proxy. The scenario is then as follows: ALTO discovery client <---> HTTP proxy <---> SWD discovery server In that setting, unless I miss something, it can be difficult for the SWD discovery server to figure what ALTO server could provide guidance to clients behind the proxy. Also, note that the ALTO server does not have to run on port 80 or 443, i. e., ALTO queries may or may not have to pass through the HTTP proxy themselves. Any middlebox scenario is difficult for ALTO discovery, similar like NAPT. But middleboxes on port 80 and 443 are quite frequent. And I don't think it is well understood how this affects ALTO discovery. > > Right now, all the points are speculation. It might be > doable to engineer an ALTO discovery solution based on > draft-jones-simple-web-discovery, if it becomes an IETF > standard. But, as of now, I don't really understand what the > benefit would be for ALTO. > > Unifying protocol stack to a single one, HTTP(S), and relying > in a fully controled server framework. And there is another > reason related to trust and > security: while HTTPS is well understood and easy to deploy, > DNSsec is in not such a good situation. A trustworthy > discovery mechanism would be much simpler to implement and > easier to adopgt by using HTTPS... I am not a security expert. But in a typical access network scenario both the network (DHCP infrastructure) and the DNS server is under control of the access network operator. If there is a successful attack on the DNS infrastructure, there are probably worse problems than ALTO server discovery. Also, please have a look at the security consideration section in draft-ietf-alto-server-discovery. The main attack on ALTO server discovery is to provide a forged ALTO server URI, e. g., an server that provides suboptimal guidance regarding peer-selection. While "worse-than-random" traffic optimization is certainly not optimal, it doesn't seem to result in a tremendous security issue neither. Thus, unless I miss something, I don't see a significant security and trust benefit for HTTP(S)-based ALTO discovery. Michael > If the current status of draft-jones-simple-web-discovery we > could even dare incorporate in the draft the mechanisms there > that are related to ALTO discovery. As far as I can tell, > they are rather straightforward. > > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: di...@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. > Puede consultar nuestra política de envío y recepción de > correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We > only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
