Hi Michael, On 14 Nov 2012, at 21:45 , Scharf, Michael (Michael) wrote: > 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.
And, as I said, that's a good point in what relates to that draft itself. > 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". It is natural in the sense that you conceivably write a full ALTO client using high-level interfaces to HTTP(S) connections (I think we all know many of them in Java, Python or Perl just to name a few languages), without requiring any additional interface to network services, with the exception of the requirements for discovery. > 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. My experience with teams operating production DNS servers is that they are more keen on deploying "well-known" records (note the quotes, I know U-NAPTR is part of the standard records) like the CNAMEs that would be required in the case of using HTTP(S) for discovery. Furthermore, the additional level of indirection can be an advantage for operations since: 1) You won't need to coordinate the DNS and ALTO teams if they are not the same. DNS being a currently critical infrastructure makes it harder to tweak. 2) Updates won't require dealing with the usual DNS TTL procedures. > 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. Agreed. No intention to re-open this issue anyway. > 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. The point here is how operations are organized. You assume DHCP and DNS (and ALTO) management correspond to the same unit. My point is that whoever is in charge of the ALTO content (not the Web servers themselves) could make the updates in the case of HTTP(S) discovery. > No. The sole purpose for the discovery is to find the URI of a suitable ALTO > server. But, following the same model of U-NAPTR, I guess many ALTO queries could be peformed as well. But, anyway, I acknowledge it was a rather rhetorical question. > 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. But the problem you describe would be the same in the case of normal ALTO queries unless explicit client identification is required. The usage of HTTP(S) transparent middleboxes is an issue for any protocol relying on that transport. > 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. Sure. But does not preclude that ALTO server discovery would be an additional service at risk. > 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. Indeed, that applies for the current ALTO use cases. But if we think about those discussed in the i2aex BoF, and the extensions recently proposed on Scheduled Maps that depicts usage for information on SDN policies, trust become a much more important part of the equation. > Thus, unless I miss something, I don't see a significant security and trust > benefit for HTTP(S)-based ALTO discovery. Yeah. You are probably right in that these trust considerations apply to use cases outside of the current scope. But I still think they are relevant for the future evolution of the protocol. 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
