Re: [alto] Meeting Info for Tuesday 07/18/2023
Hi Jordi, On topic C, I’d suggest we could use as base for discussion this post I made to the list: https://mailarchive.ietf.org/arch/msg/alto/c-pFeENnBa3t1HcVlgHtArT6uuE/ I have seen Ayoub (or another kind editor) has added what is mentioned there to the root document… Be goode, -- “Esta vez no fallaremos, Doctor Infierno” Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/dr2lopez/ e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com> Mobile: +34 682 051 091 - On 18/7/23, 11:56, wrote: Dear all, This is a friendly reminder that we will have our ALTO weekly meeting today Tuesday, 07/18/2023, at 9:00 am EST (3:00 pm CET and 9:00 pm Beijing Time). Agenda: (Please suggest new items as necessary) - Address comments from RFC Editor on ALTO Performance Metrics drafts. - IETF 117. - Chairs proposed this agenda: https://datatracker.ietf.org/doc/agenda-117-alto/ - Discussion about presentations - Hackathon projects - ALTO Future Work: - List of topics: https://mailarchive.ietf.org/arch/msg/alto/uIFD6Dhikfu4J4PYcpJTbsiXbnE/ - Topic A: https://mailarchive.ietf.org/arch/msg/alto/nSBb2fJwwEEEeZ-Xxw-OmHhJdTs/ - Topic B: https://mailarchive.ietf.org/arch/msg/alto/IXYPC1joF17oPJ7MWz5NDplAqKk/ - Topic C: WIP - Topic D: https://mailarchive.ietf.org/arch/msg/alto/IEAyQ2kv49AvT1hIGfYkHWLxisY/ - Material: - Root document for topics discussion: https://docs.google.com/document/d/1rpziU7NZEE8f84XkJSjMhEIHUA5G7rXkGB5c_7UFxUY/edit - Root ticket for ALTO future work proposals: https://github.com/ietf-wg-alto/wg-materials/blob/main/FutureALTO/alto-direction-of-work.md ALTO Scrum Dashboard: -- - https://github.com/orgs/ietf-wg-alto/projects/1/views/2 Bridge: - - Join from the meeting link: https://ietf.webex.com/ietf/j.php?MTID=m1dd555eff4634917aaff5a927d6e2c68 - Join by meeting number (access code): 2424 884 8159 - Meeting password: ymKtkapb394 ALTO Meeting Minutes: - https://github.com/ietf-wg-alto/wg-materials/blob/main/meetings-ietf-alto/ietf-alto-2023.md Thanks, Jordi, on behalf of ALTO Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>. We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established with the recipient or with the entity to which it is linked. You may contact the data controller and exercise your rights by writing to privacidad@telefonica.com<mailto:privacidad@telefonica.com>. You may consult additional information on the processing of your data in our Privacy Policy<https://www.telefonica.com/
Re: [alto] Follow-up on the Security/Trust aspects in ALTO
Hi again, I forgot to include the reference to the YANG provenance draft. Now it is included in the updated text below… I owed you a more detailed analysis of the implications I discussed during the call on security and trust implications in ALTO. First of all, my apologies for the delay, justified by the overload of this period. I have finally found some time, now that I am trying to focus on the coming IETF meeting, and therefore I am sharing with you my reflections. When talking about security and trust in a network capability exposure protocol like ALTO, I believe we have to consider four different dimensions: · The security of the transport protocol (typically, TLS, though we could even think of other potential encapsulations and consider IPsec, SSH…), focused on the specific profiles and requirements for this protocol. That would include cyphersuites, requirements for (mutual) authentication, certificate profiles, etc. Another aspect to take into account is how parameters derived from the secure transport (think of the identities in the certificates) can be forwarded to the application relying on ALTO for making its decisions. · The security of the transferred data itself, associated to data serialization. Given the nature of ALTO, the use of mechanisms for signing (and even encrypting) JSON would be the obvious choice, though it would be interesting to analyze the options at hand, to avoid reinventing a full secure-ALTO protocol, and maximize flexibility while addressing relevant use cases for securing ALTO statements. · The provenance of the data, in order to properly record the origin and history of the data being exposed using ALTO. This includes the different data sources aggregated by the ALTO server and the possible re-use of stored or post-processed ALTO statements. I have submitted a proposal on YANG provenance (https://datatracker.ietf.org/doc/draft-lopez-opsawg-yang-provenance/) that could be applicable here. · The expression of security properties (and trust assessment. Note the difference) as ALTO metrics. This would require an extension to the protocol, of a nature similar to the ones being discussed for other aspects like energy consumption. If you find this discussion interesting enough, I’d be more than happy to make an introduction to these matters, with the idea of exploring the WG interest on the different aspects, at the coming IETF 117, time permitting… Be goode, -- “Esta vez no fallaremos, Doctor Infierno” Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/dr2lopez/ e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com> Mobile: +34 682 051 091 - Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-
[alto] Follow-up on the Security/Trust aspects in ALTO
Hi, I owed you a more detailed analysis of the implications I discussed during the call on security and trust implications in ALTO. First of all, my apologies for the delay, justified by the overload of this period. I have finally found some time, now that I am trying to focus on the coming IETF meeting, and therefore I am sharing with you my reflections. When talking about security and trust in a network capability exposure protocol like ALTO, I believe we have to consider four different dimensions: * The security of the transport protocol (typically, TLS, though we could even think of other potential encapsulations and consider IPsec, SSH…), focused on the specific profiles and requirements for this protocol. That would include cyphersuites, requirements for (mutual) authentication, certificate profiles, etc. Another aspect to take into account is how parameters derived from the secure transport (think of the identities in the certificates) can be forwarded to the application relying on ALTO for making its decisions. * The security of the transferred data itself, associated to data serialization. Given the nature of ALTO, the use of mechanisms for signing (and even encrypting) JSON would be the obvious choice, though it would be interesting to analyze the options at hand, to avoid reinventing a full secure-ALTO protocol, and maximize flexibility while addressing relevant use cases for securing ALTO statements. * The provenance of the data, in order to properly record the origin and history of the data being exposed using ALTO. This includes the different data sources aggregated by the ALTO server and the possible re-use of stored or post-processed ALTO statements. I have submitted a proposal on YANG provenance () that could be applicable here. * The expression of security properties (and trust assessment. Note the difference) as ALTO metrics. This would require an extension to the protocol, of a nature similar to the ones being discussed for other aspects like energy consumption. If you find this discussion interesting enough, I’d be more than happy to make an introduction to these matters, with the idea of exploring the WG interest on the different aspects, at the coming IETF 117, time permitting… Be goode, -- “Esta vez no fallaremos, Doctor Infierno” Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/dr2lopez/ e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com> Mobile: +34 682 051 091 - Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição Le informamos de que el responsable del tratamiento de sus datos es la entidad del Grupo Telefónica vinculada al remitente, con la finalidad de mantener el contacto profesional y gestionar la relación establecida con el destinatario o con la entidad a la que está vinculado. Puede contactar con el responsable del tratamiento y ejercitar sus derechos escribiendo a privacidad@telefonica.com<mailto:privacidad@telefonica.com>. Puede consultar información adicional sobre el tratamiento de sus datos en nuestra Política de Privacidad<https://www.telefonica.com/es/telefonica-politica-de-privacidad-de-terceros/>. We inform you that the data controller is the Telefónica Group entity linked to the sender, for the purpose of maintaining professional contact and managing the relationship established wit
Re: [alto] APN6: Application-aware IPv6 Networking
Hi Richard, Though I was not able to join you for this side meeting, I am interested indeed, and thankful to Sabine (who let me know about it!). Be goode, -- "Esta vez no fallaremos, Doctor Infierno" Dr Diego R. Lopez Telefonica I+D https://www.linkedin.com/in/dr2lopez/ e-mail: diego.r.lo...@telefonica.com<mailto:diego.r.lo...@telefonica.com> Tel: +34 913 129 041 Mobile: +34 682 051 091 -- On 21/11/2019, 11:10, "alto on behalf of Y. Richard Yang" mailto:alto-boun...@ietf.org> on behalf of y...@cs.yale.edu<mailto:y...@cs.yale.edu>> wrote: Dear Shuping, Zhenbin, Thank you so much for the more pointers on APN6! As we discussed, both teams will together to organize a next side meeting soon, which should be more comprehensive, and both divide the problem space (AAN, NAA, etc) and at the same time achieve a coherent bigger framework. To all: if you are interested in the larger application-network integration space, please do get in touch with us. We will post on related mailing lists so that all can participate. The benefit of getting in touch now is that we may have some f2f time for those in Singapore right now. Richard On Thu, Nov 21, 2019 at 7:35 AM Pengshuping (Peng Shuping) mailto:pengshup...@huawei.com>> wrote: Dear all, In the ANI Side meeting, we have presented APN6, which is AAN (Application-aware Network), that is, to convey application information into the network and make the network aware of applications and their requirements. We have done work in this area. Your reviews and comments are very welcomed. Thank you! Please find the drafts on the APN6. https://tools.ietf.org/html/draft-li-apn6-problem-statement-usecases-01 https://tools.ietf.org/html/draft-li-apn6-framework-00 The IETF105 APN6 Side meeting materials can be found here: https://github.com/shupingpeng/IETF105-Side-Meeting-APN6 Best regards, Shuping ___ alto mailing list alto@ietf.org<mailto:alto@ietf.org> https://www.ietf.org/mailman/listinfo/alto -- Richard Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição ___ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
Re: [alto] Pub-sub interfaces
Hi Richard, A Message Broker is a general construct in pub-sub environments, acting as mediator for publishers and subscribers, matching interests and announcements, and enforcing access policies. I'd think of it as an essential part of the pub-sub middleware, not necessarily as a central server or a bottleneck. I agree the document is rather general: bear in mind it is a first statement addressed to a WG like I2RS, with very broad goals and in its initial stages. My intention was precisely to provide it as an initial reference for the ALTO crowd to consider and discuss on use cases. The one you mention is the one I had in mind. More complicated ones could include hierarchical aggregation, composition of information from different servers, or data filtering driven by policies. I guess this could be applicable in inter-domain scenarios. Be goode and have an Extremely Goode New Year, On 31 Dec 2013, at 03:05 , Y. Richard Yang wrote: Hi Diego, Thanks a lot for posting the link. I read the document and it was a well-written document. If the document provides more text to review the two pub-sub models and how they may apply to I2RS, it will be more self-contained. A key proposal from the document, I see, is the introduction of a Message Broker. A main motivation appears to be scalability, i.e., to avoid the P * S problem, where P is the number of publishers and S the number of subscribers. One problem of the document is that it appears to be quite broad, where either applications or routers can publish and subscribe (not sure if routers will subscribe though), and many types (e.g., router/device status changes, app info changes? policy changes) are mentioned. This may imply that the schema of the pub-sub system can be quite complex or very generic. We know generic, well-used systems such as Google Chabby (Zookeeper), and hence I will wait to see the details of any specific proposals, on whether they will apply to ALTO. A concrete issue that I will look for is on how to encode updates of a large data set, e.g., a Network/Cost Map. As a simple, related use case of their scheme, an ALTO Server can be a publisher to push any incremental updates to the Media Broker, who can then handle a large number of subscribers. More complicated use cases or ALTO should develop its own sub-pub mechanism? Happy New Year! Richard On Fri, Dec 27, 2013 at 10:58 AM, Diego R. Lopez mailto:di...@tid.es>> wrote: Hi, Some time ago we discussed about the pros and cons of using Websockets for implementing server-to-client notifications and I mentioned the possibility of using a pub-sub schema for creating a general notification framework. While reviewing some messages during my end-of-year tidying I came through this draft: http://tools.ietf.org/html/draft-camwinget-i2rs-pubsub-sec-00 contributed to I2RS, that discusses the application of the model in the access to a programmatic interface to the routing system. I think it provides a good overview of the model, and that many of the considerations are applicable to ALTO notifications, and even more to a generalized topology service. 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<mailto: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<mailto:alto@ietf.org> https://www.ietf.org/mailman/listinfo/alto -- -- = | Y. Richard Yang mailto:y...@cs.yale.edu>> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/| = -- "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
[alto] Pub-sub interfaces
Hi, Some time ago we discussed about the pros and cons of using Websockets for implementing server-to-client notifications and I mentioned the possibility of using a pub-sub schema for creating a general notification framework. While reviewing some messages during my end-of-year tidying I came through this draft: http://tools.ietf.org/html/draft-camwinget-i2rs-pubsub-sec-00 contributed to I2RS, that discusses the application of the model in the access to a programmatic interface to the routing system. I think it provides a good overview of the model, and that many of the considerations are applicable to ALTO notifications, and even more to a generalized topology service. 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
Re: [alto] extension questions and comments
Hi, There are some discussions ongoing around something called flow metadata, associated with draft-eckert-intarea-flow-metadata-framework, that I think head somehow in that direction. Be goode, On 28 Oct 2013, at 10:54 , Reinaldo Penno (repenno) wrote: > I also think seedorf-lmap is a very interesting draft. > > But what I'm most interested in a way to make maps writable. I want an app > to be be able to write to a map therefore influencing its own cost and > attributes. > > From: Greg Bernstein > Date: Monday, October 28, 2013 10:48 AM > To: "alto@ietf.org" > Subject: [alto] extension questions and comments > > Hi ALTO extension folks, as I'll not be making it up to Vancouver :-( , here > are some questions/comments. > These comments/questions are from the perspective of creating an ALTO > topology service (suitable for large bandwidth and SDN applications). > http://tools.ietf.org/html/draft-scharf-alto-vpn-service-01 > ALTO for VPNs: Way back when we started talking about "topology" like > extensions. The concept of ALTO for "controlled or partially controlled" > environments was floated. It seems that a VPN type of service would be the > exemplar of such an environment and hence pave the way for "restricted > environment" use of ALTO. Questions: Are there specific additions to the > REST API to offer this some kind of security, i.e., to keep others from > gaining information about a customers VPN? Or would a general approach to > security of this interface be specified? > http://tools.ietf.org/html/draft-song-alto-overlay-routing-00 > Extensions for Multiple path choices: In our large bandwidth work we > considered both path representations as well as graph representations. This > proposal would extend ALTO by reporting costs on multiple possible paths > between a source and destination. Hence could also work for the large > bandwidth case with appropriate extensions. Both in this draft and the VPN > draft, we may have the situation where the client uses ALTO information to > not only make a choice but then relay that choice back to the network via > some type of "reservation interface". > http://tools.ietf.org/html/draft-wu-alto-te-metrics-00 > Defines costs metrics based on OSPF-TE. We would need for such metrics for > the "general" topology service. > http://tools.ietf.org/html/draft-roome-alto-pid-properties-00 > PID properties -- Comments: This is a step on the way to a "NID" that we > would use in a graph topology (multi-switch) representation, i.e., where we'd > define a Node with Id and properties. > http://tools.ietf.org/html/draft-seedorf-lmap-alto-02, > http://tools.ietf.org/html/draft-seedorf-cdni-fci-alto-00 > Very interesting applications. Any interest from the authors of these drafts > in bandwidth/topology type information? > Best Regards > Greg B. > > > On 10/22/2013 1:02 PM, Vijay K. Gurbani wrote: >> Folks: As you prepare slides, etc. for your ALTO extensions, please >> consult the latest institutional memory on how to taxonomize or classify >> the extensions; this was captured rather succinctly and successfully >> during the Berlin IETF side meeting [1]. >> >> Enrico and I will be looking to see how we can group the various >> extensions under this ontology. It will make it tractable to understand >> and appreciate the extensions as we grapple with them. >> >> Thanks, >> >> [1] http://www.ietf.org/proceedings/87/minutes/minutes-87-alto#ad-hoc >> >> - vijay > > > -- > === > Dr Greg Bernstein, Grotto Networking (510) 573-2237 > > > ___ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto -- "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
Re: [alto] Clarifying Cost Map Dependencies on a Network Map
I am not trying to open again the discussion on HTTP-based discovery we had some time ago, but it looks to me that situations like the one described by Wendy could imply that we'd need some mechanism for optionally providing metadata as a result of the initial discovery process. Unless I am missing something, this would be a case for an extended HTTP-based discovery. I think we could discuss on this during the extended evening session that Enrico announced for Wednesday. Be goode, On 24 Jul 2013, at 09:48 , Sebastian Kiesel wrote: > On Tue, Jul 23, 2013 at 04:52:35PM -0400, Wendy Roome wrote: >> Here's why an IRD returned by ALTO discovery must must have a default >> network map. Consider an ALTO client that gets the server URI via discovery. >> By definition, a discovery client must be provider-independent. Because >> resource ID names are provider-specific, a discovery client cannot be >> pre-configured with a map ID. Hence any IRD returned by discovery MUST mark >> one of its maps as the default. If not, a discovery client can't decide >> which network map to use. >> >> Of course, there'd be no problem if ALTO discovery could return a map ID as >> well as a URI. But I gather that's not possible. > > The current discovery procedures do not support that, and it seems to me > that this would only move the problem to another subsystem instead of > solving it - if you cannot decide which map to mark as default in the > IRD, how could you decide which map name to indicate as default using a > to-be-defined extension of the discovery mechanism? > > Thanks > Sebastian > > ___ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto -- "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
Re: [alto] Security problem: DoS attacks via overload
Hi, On 22 Mar 2013, at 14:37 , Wendy Roome wrote: > Put it another way: I think the decision to offer a full cost-map is a > "policy" issue rather than "mechanism" issue -- and I think RFCs should > define "mechanisms", and leave the "policies" to the folks who implement > those protocols. I realize that opinion may be extreme, so the rest of > you, feel free to comment! A short comment: I fully agree with you in this respect... 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
Re: [alto] Security problem: DoS attacks via overload
Hi, Since I am in the same situation as Wendy (in terms of being old enough to remember when the Internet was small and even when it barely existed) I like the idea of the "Request Too Large" error code, that reminds me what a LDAP server returns when a search would include more entries than what the server configuration allows to be returned. And I must say I support the idea of making full cost maps optional. Replacing MUST for a SHOULD (and making clear that only the "Request Too Large" error is acceptable to not satisfy it) should be enough to avoid the overload risk while staying as close as possible to the minimum that makes Sebastian feel uneasy... 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
Re: [alto] ALTO vs ssl/tls
This definitely makes sense to me... On 5 Mar 2013, at 08:44 , Ben Niven-Jenkins wrote: > I think we should separate authentication from encryption/integrity more > explicitly as I think there may be cases where one is required but not the > other. > > So how about: > > "When one or more of server or client authentication, encryption or integrity > protection are required, an ALTO Server MUST support SSL/TLS [RFC5246] as a > mechanism. For cases such as a public ALTO service or where there exists an > implicit trust relationship between the client and the server, SSL/TLS may > not be necessary." > > Ben > > On 4 Mar 2013, at 19:35, Y. Richard Yang wrote: > >> Hi Wendy, >> >> The context of the change is the following AD Review: >> >> " What security mechanism to use in what scenario. The considerations >> elaborate on the use of SSL/TLS, but it is not clear when to use it. In >> general, it seems to be really good, at least by today, to mandate the use >> of HTTPS in almost any scenario where the traffic crosses a publicly >> available infrastructure, e.g., the general Internet, wireless access >> networks, etc. Conversely, it can be good to always mandate the use of HTTPS >> and to list exceptional cases where it is required, i.e., CDNI peering >> point." >> >> How about the following revision: >> >> "When server and/or client authentication, encryption, and/or integrity >> protection are required, ALTO Server MUST support SSL/TLS [RFC5246] as a >> mechanism. For cases such as a public ALTO service or there is an implicit >> trust relationship between the client and the server, SSL/TLS may not be >> necessary." >> >> Richard >> >> On Mon, Mar 4, 2013 at 1:47 PM, Wendy Roome >> wrote: >> I suggest just putting it back the way it was -- "An ALTO server MAY use >> ssl/tls ..." Let the market decide. Providers who want to protect their >> data will only provide secure ALTO servers. Fine! But if someone wants to >> provide ALTO as a public service, and they don't care who uses it, why >> should they be required to use ssl/tls? >> >> Also, ssl/tls is independent of the ALTO protocol spec. It's not like the >> protocol defines client ids, how to authenticate clients, etc. >> >> Finally, wasn't one of our goals to allow proxy servers to cache full cost >> maps, to cut the load on ALTO servers? Wouldn't the ssl/tls requirement >> prevent that? >> >>- Wendy Roome >> >> >> On 03/04/2013 13:23, "Reinaldo Penno (repenno)" wrote: >> >>> Agreed. It would be good if we added wording such as: >>> >>> "An ALTO Server MUST support TLS/SSL unless there is an implicit trust >>> relationship between client and server.." >>> >>> Implicit trust could mean that client and server are operated by same >>> entity, or sit in some trusted network, etc. >>> >> >> >> ___ >> alto mailing list >> alto@ietf.org >> https://www.ietf.org/mailman/listinfo/alto >> >> ___ >> alto mailing list >> alto@ietf.org >> https://www.ietf.org/mailman/listinfo/alto > > ___ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto -- "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
Re: [alto] Discussion II: Unifying cost-mode and cost-type to a single type
Hi,
As said some time ago, I do support the idea. It is much better structured and
simplifies processing (at both sides, I'd say) And it posseses a taste close to
the good-ole MIME types I cannot avoiud to appreciate.
Will go through the detailed text later and provide comments (if any) but let's
get the ball rolling!
Be goode,
On 15 Feb 2013, at 21:23 , Wendy Roome wrote:
> To return to this issue, I suggest we unify them, so that we have Cost
> Types -- period. The "Mode" becomes a property of the Cost Type. So if a
> server provides numerical & ordinal routingcosts, it provides *two*
> separate Cost Types, say "routingcost" and "routingcost-ord".
>
> I believe the result will simplify both clients and servers, and make it
> easier for servers to introduce additional cost types.
>
> My suggestion is to extend the Information Resource Directory with a list
> of definitions for each Cost Type the server supports. Each Cost Type
> definition would give the name of the Cost Type, the mode, and other
> attributes. Currently the Information Resource Directory is a dictionary
> with one item, "resources". So I propose adding a second item named
> "cost-types," whose value is a list of cost-type definitions, as in
>
> "cost-types" : [
>{
> "name" : "routingcost",
> "value" : "number",
> "mode" : "numerical",
> "measures" : "delay",
> "description" : "Standard routing cost",
>}, {
> "name" : "hopcount",
> "value" : "number",
> "mode" : "numerical",
> "measures" : "hops",
> "description" : "Simple hop count",
>}, {
> "name" : "routingcost-ord",
> "value" : "number",
> "mode" : "ordinal",
> "measures" : "delay",
> "description" : "Ordinal routing cost",
>}
> ]
>
> Then pretty much delete every reference to a field named "cost-mode".
>
>
>
> To get the ball rolling, I've attached proposed replacements for
>
> Section 5.1. Cost Attributes
> Section 6.7.2. Encoding Section 6.7.3. Example
>
> If those don't survive the list server, let me know and I'll put them up
> on a web server.
>
> If y'all like this idea, I'd be happy to help with the editing.
>
> - Wendy Roome
>
>
>> Date: Mon, 28 Jan 2013 23:08:23 +
>> From: "Reinaldo Penno (repenno)"
>> Subject: [alto] ALTO Protocol Outstanding Issue II: Unifying cost-mode
>> and cost-type to a single type
>>
>> Discussion II: Unifying cost-mode and cost-type to a single type
>>
>> e.g., routingcost-num and routingcost-ord
>>
>> Having a single type simples the protocol since there is just one
>> parameter when indicating cost. But it will impact current
>> implementations and might loose flexibility.
>>
>> Proposal: Leave it as is.
>>
>> Thanks,
>>
>> Reinaldo
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
--
"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
Re: [alto] Should we allow relative URIs in resource directories?
Hi,
I think allowing only absolute URIs would translate into simpler mechanisms to
build them, and better understanding by human readers trying to debug based on
ALTO outputs, but I acknowledge these are limited advantages if there are any
other reasons for allowing relative URIs.
Be goode,
On 12 Feb 2013, at 15:33 , Ben Niven-Jenkins wrote:
> Wendy,
>
> I see no reason to restrict to absolute URIs.
>
> Currently section 6.7.2 of the ALTO protocol spec states:
>
> uri A URI at which the ALTO Server provides one or more Information
> Resources, or an Information Resource Directory indicating
> additional Information Resources.
>
> Would adding a reference to section 4.1 of RFC3986 be sufficient, e.g.
>
> uri A URI reference (as per section 4.1 of [RFC3986] to one or more
> Information Resources, or an Information Resource Directory
> indicating additional Information Resources.
>
>
> Ben
>
> On 11 Feb 2013, at 16:53, Wendy Roome wrote:
>
>> In general URIs can be relative as well as absolute. So if an ALTO
>> server's resource directory has the URI
>> "http://alto.example.com/directory";, directory entries like
>> { "uri" : "/networkmap", }
>> or
>> { "uri" : "costmap/num/routingcost", ...}
>> should be legal and should resolve to "http://alto.example.com/networkmap";
>> and "http://alto.example.com/costmap/num/routingcost";, respectively.
>>
>> However, our examples only use absolute URIs. As far as I can tell, draft
>> 13 doesn't say anything about relative URIs.
>>
>> So I think we should either explicitly allow relative URIs -- and use them
>> in examples in the RFC and in the next interop -- or else forbid them.
>> That would affect Sections 6.7.2 & 6.7.3.
>>
>> Comments?
>>
>> - Wendy Roome
>>
>>
>> _______
>> alto mailing list
>> alto@ietf.org
>> https://www.ietf.org/mailman/listinfo/alto
>
> ___
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
--
"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
Re: [alto] Unifying cost-mode and cost-type
Hi, I think your proposal on adding this metadata on what an ALTO server provides makes a lot of sense, especially if we think about the additional usages of ALTO that were originally discussed in the i2rs BoF in Paris, and that I'd say have raised so much expectation among the SDN community, among others. Therefore, I'd like very much to see this discussion happening within the ALTO group, mostly once we have been able to complete the current set of documents and we are in the position of re-chartering the group along the lines discussed in the Paris BoF. Be goode, On 30 Jan 2013, at 20:12 , Wendy Roome wrote: > I realize it's late to make changes, but I really think unifying type & > mode makes a lot of sense. Here's my suggestion: extend the "resource > directory" to include a generalized description of the cost-types that the > server provides. I won't suggest a syntax -- too early for that!! -- but > here's what the description should provide for each distinct type: > > * The type name. This is what clients give in the cost-type parameter. > > * The value type. "numerical" & "string" are obvious possibilities. > > * Linear: a boolean flag. True means this numeric value is linear. > False means values are not linear. This takes the place of > the ordinal/numerical mode. > > * Category: What this cost measures: "delay", "hops", "cost", "other". > Here "cost" means money. > > * Description: An optional free-form description of this cost type. > For human consumption, to be used when investigating a new ALTO server. > > * URL: An optional url with a detailed description of this cost type. > For more involved "Descriptions", of course. This can be in > multiple languages, of course. > > Yes, the change would be painful, but I think it will simplify the > protocol, servers and clients -- AND it will make it easier for servers to > add new cost types. > > To simplify clients, we might reserve a few type names, such as > routingcost-numerical > routingcost-ordinal > hopcount-numerical > hopcount-ordinal > and require them to have the obvious descriptions. > > - Wendy Roome > > > > > On 01/29/2013 15:00, "alto-requ...@ietf.org" wrote: > >> Date: Mon, 28 Jan 2013 23:08:23 + >> From: "Reinaldo Penno (repenno)" >> To: "alto@ietf.org" >> Subject: [alto] ALTO Protocol Outstanding Issue II: Unifying cost-mode >> and cost-type to a single type >> Message-ID: >> <45a697a8ffd7cf48bcf2be7e106f060408ff5...@xmb-rcd-x04.cisco.com> >> Content-Type: text/plain; charset="us-ascii" >> >> Hello, >> >> Please send your comments to the list in the next 2 weeks. Silence means >> we will go with the proposal. >> >> Discussion II: Unifying cost-mode and cost-type to a single type >> >> e.g., routingcost-num and routingcost-ord >> >> Having a single type simples the protocol since there is just one >> parameter when indicating cost. But it will impact current >> implementations and might loose flexibility. >> >> Proposal: Leave it as is. >> >> Thanks, >> >> Reinaldo >> > > > ___ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto -- "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
Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments
Hi Sebastian, As you wish. As I told Reinaldo recently, we are working on an ALTO server focused on some of the scenarios discussed during the i2aex BoF in Paris, and we plan to implement "well-known" URL, HTTP-based discovery. Once we have it I will get back to group with a detailed proposal. Anyway, I would be grateful if you could point me where in this discussion I committed the horrible sin of "marketing blah blah" you are accussing me of. Be goode, On 18 Dec 2012, at 21:44 , Sebastian Kiesel wrote: > Hi Diego, > > On Sun, Dec 09, 2012 at 10:38:37PM +, Diego R. Lopez wrote: >> Hi, >> >> On 19 Nov 2012, at 18:01 , Sebastian Kiesel wrote: >> >>> I propose to add such a discussion to the Deployment Considerations >>> document, if we want to have one at all. The discovery document should >>> contain a technical specification as short and as precise as possible. >> >> An appendix is clearly out of the techhnical specification and discusses >> an additional aspect. In this case an alternative protocol applicable to >> other potential use cases... > > For now I still would say that the discussion of a specific use case > without protocol specification (i.e., gap analysis for existing > protocols, things to consider, special parameters to use, etc.) should > go into the deployment considerations document. We created this > document exactly for that kind of information. The specification of a > different solution approach should go into a separate draft - at least > for the initial version, maybe it makes sense to merge it into a common > framework later. Marketing blah blah about the alleged advantages of an > unspecified protocol should go nowhere, we just don't need that. > A single sentence that there are other solution approaches being > considered, with references to other drafts, would nicely fit into the > introduction. > > But maybe I will change my mind if we have a clearer idea what > you would like to see in the appendix. So please propose text. > > Thanks > Sebastian -- "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
Re: [alto] Reminder: WGLC for server-discovery ends Friday!
Hi, After the discussion with Sebastian on HTTP discovery and the agreement on leaving it as a possibility for covering additional use cases as part of an appendix, I do support moving this forward. Be goode, On 10 Dec 2012, at 16:01 , Vijay K. Gurbani wrote: > Folks: draft-ietf-alto-server-discovery-06 is in WGLC that will end this > Friday. > > Thus far, there have been no comments on it on the list. Enrico and I > urge the working group participants to perform a review of the > document. Short statements in support of moving the work ahead, > or statements that provide constructive solutions for any aspect lacking > in the draft, are helpful. Please do post such statements on the list. > > Thank you, > > - vijay -- "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
Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments
Hi, On 19 Nov 2012, at 18:01 , Sebastian Kiesel wrote: > I propose to add such a discussion to the Deployment Considerations > document, if we want to have one at all. The discovery document should > contain a technical specification as short and as precise as possible. An appendix is clearly out of the techhnical specification and discusses an additional aspect. In this case an alternative protocol applicable to other potential use cases... 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
Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments
Hi Michael, Sorry for getting back to this so late: I have been caught on a spiral of corporate commitments really difficult to get rid of... We can discuss about those of my statements you don't agree with and those of your statement I don't agree with in front of a couple of beers along next meeting. I think your proposal on an appendix makes sense. Let's go for it and make things happen. Be goode, On 19 Nov 2012, at 17:54 , Scharf, Michael (Michael) wrote: > Diego, all, > > I won't give further pushback, even if I don't agree to quite a number of > your statements. Just one further example to explain why SWD won't solve all > problems: Even if we replace U-NAPTR by HTTP(S), according to RFC 5986, the > ALTO client still needs access to DHCP options, which is yet another > non-HTTP(S) interface to care about. > > For what it is worth, I am convinced both a DNS-based and a HTTP(S) solution > can be engineered, each with pros and cons. Yet, the former variant is much > better understood in the IETF, and I fail to see a fundamental benefit of SWD > that would compensate this. > > In order to move forward, if this helps to sort this issue, I think that we > could add a non-normative section to the current draft (or, better, an > appendix) that discusses an alternative HTTP-based discovery, in case that > such a solution gets widely used in future. It could for instance summarize > pros and cons according to this e-mail thread, and leave it up to a future > document to standardize this variant (possible, after the mechanism is better > worked out in the IETF). It is pretty clear anyway that the current ALTO > discovery specification does not address all possible use cases of ALTO (cf. > third party discovery). > > Any thoughts on that proposal? > > Michael -- "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
Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments
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
Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments
Hi Sebastian, On 15 Nov 2012, at 21:26 , Sebastian Kiesel wrote: > As you can see the ALTO4ALTO draft has expired quite some time ago. > We've been discussing architectural options for quite a while now > and there was not much positive feedback about this draft so far. > > My personal favorite topic is still the third-party discovery. If we > had a working solution for that we could also use it for the resource > consumer initiated discovery. > > But 3pdisc causes lots of headaches so we decided to push forward a > simple solution at least for resource consumer initiated discovery. From > a technical point of view I think both is feasible, DHCP/DNS based > discovery as well as ALTO4ALTO style discovery, but I cannot see a clear > winner. From procedural point of view the DHCP/DNS way has advantages > as it is based on more established and solid base protocols. As I said in my reply to Michael, probably it makes sense to consider the HTTP(S) based discovery for the future evolution of the protocol (as mostly discussed in the i2aex BoF), and stay in the DNS path so we have a first version of all required mechanisms soon. 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
Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments
Hi Sebastian, On 9 Nov 2012, at 22:00 , Sebastian Kiesel wrote: > I think we could even do that within the ALTO protocol, see > http://tools.ietf.org/id/draft-kiesel-alto-alto4alto-00.txt but I also > believe that in a multi-domain scenario this inter-ALTO-server mesh > structure would be much more cumbersome than relying on DNS, and a DNS > resolver stub is anyway included in virtually every networked device. Was not aware about this draft, thanks for the pointer. I think this could be the base for what I mentioned in my last reply to Michael on relying on only-ALTO documents to make the specification. I still think that a single GET query sounds simpler than a direct access to the DNS interface, as well as the trust considerations are applicable. What would you think of leaving the current discovery document as it is now and exploring the possibility of aligning HTTPS discovery with this ALTO4ALTO idea? 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
Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments
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. > 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. > 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 > - 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. > - 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? > 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... 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
Re: [alto] [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments
Hi, As I understand it, the proposal does not intend to keep a registry of the URIs used for discovery (it is a parameter for a query using HTTP GET) and, therefore, ALTO could mandate its own URI, in the same way the U-NAPTR lookup defines the string to be queried. The requirements on external registrations are essentially the same in both cases (none, I think). My point is that an ALTO client would have to rely only in queries aligned with the rest of the transport protocol, i.e. plain HTTP(S), and not be required to include support for specific DNS queries. Be goode, On 7 Nov 2012, at 15:50 , Scharf, Michael (Michael) wrote: > After briefly scanning through draft-jones-simple-web-discovery, which seems > to be an individual draft, I wonder how the ALTO service would be registered > in this solution. The text states: "The definition of URIs used to identify > principals and services are outside the scope of this specification." If such > issues are not clear as of now, it is unclear to me whether this is indeed a > mature technology. > > At first sight, compared to that, the U-NAPTR lookup is a well-understood > mechanism used by other IETF protocols with similar requirements like ALTO. > > Michael > -- "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
[alto] Fwd: [apps-discuss] Simple Web Discovery (SWD) Enabling Hosted Deployments
Hi, This is the recent proposal being orginated inside the OpenIDConnect community I mentioned at the mike that could be useful for not requiring an U-NAPTR lookup. I think it is worth considering as an alternative way for ALTO server discovery, since it provides a simple and coherent interface (based on HTTP GET) for this purpose. Be goode, Begin forwarded message: From: "Paul E. Jones" mailto:pau...@packetizer.com>> Subject: [apps-discuss] Fwd: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments Date: 5 November 2012 08:44:11.000 EST To: mailto:apps-disc...@ietf.org>> FYI From: Mike Jones mailto:michael.jo...@microsoft.com>> Sent: Mon Nov 05 07:55:14 EST 2012 To: "Paul E. Jones" mailto:pau...@packetizer.com>> Subject: FW: Simple Web Discovery (SWD) Enabling Hosted Deployments Paul, could you do me a favor and forward this note to the apps-discuss list so people have context on why I updated SWD? For some reason, the list doesn’t appear to be accepting my message. Thanks, -- Mike From: Mike Jones Sent: Sunday, November 04, 2012 9:21 PM To: apps-disc...@ietf.org<mailto:apps-disc...@ietf.org> Subject: Simple Web Discovery (SWD) Enabling Hosted Deployments I’ve updated the Simple Web Discovery (SWD)<http://tools.ietf.org/html/draft-jones-simple-web-discovery> specification to incorporate a means of performing discovery on domains for which it may not be possible to create a .well-known endpoint. This can often be the case for hosted domains, where it is common for e-mail to be provided but no web server. This solution was developed in discussions by the OpenID Connect<http://openid.net/connect/> working group. This draft is being published now to facilitate discussions of the need to enable discovery for hosted domains and possible solutions for doing so at the IETF Applications Area working group meeting at IETF 85 in Atlanta<http://www.ietf.org/meeting/85/>. The updated specification is available at: ·http://tools.ietf.org/html/draft-jones-simple-web-discovery-04 Changes made were: ·Specified that the SWD server for a domain may be located at the simple-web-discovery subdomain of the domain and that SWD clients must first try the endpoint at the domain and then the endpoint at the subdomain. ·Removed the SWD_service_redirect response, since redirection can be accomplished by pointing the simple-web-discovery subdomain to a different location than the domain's host. ·Removed mailto: from examples in favor of bare e-mail address syntax. ·Specified that SWD servers may also be run on ports other than 443, provided they use TLS on those ports. An HTML formatted version is available at: ·http://self-issued.info/docs/draft-jones-simple-web-discovery-04.html (This notice was also posted to http://self-issued.info/?p=891.) -- Mike ___ apps-discuss mailing list apps-disc...@ietf.org<mailto:apps-disc...@ietf.org> https://www.ietf.org/mailman/listinfo/apps-discuss -- "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
Re: [alto] WebSocket-based notifications
Hi, Just to add another bit of confusion... When reading this thread I was wondering whether a solution based on bi-directional data streams, that would keep one single connection per client-server association while allowing for different resources to be queried and updated, could be considered. What I have in mind is the use of XMPP for bi-directional ALTO interactions. Apart from the features outlined in the paragraph above, it does fit well with ALTO encoding and operational semantics, and there is a well established corpus of (many of them open) implementations. 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
Re: [alto] New Version Notification for draft-xie-alto-sdn-extension-use-cases-00.txt
Hi, Now that I have had time to re-read this thread and go through the documents, the comments and the slides we are preparing for our next meeting in Vancouver, I have come to a couple of conclusions I want to share with you. The first of all is that we'd probably have to change the title. Both the contents and the discussions around are more related to architecture than to anything else. What if we change it into something like "Architecture for ALTO and SDN interoperation" The second is related to the conditions for "network partition" (that I prefer to call "subnetwork interconnection" or "federation", if you like) in the H architecture. Hayiyong put two conditions: On 6 Jul 2012, at 19:03 , Haiyong Xie wrote: > H could allow network partition provided that the following two > conditions are satisfied: > (1) m SCs can form a mesh/peering to work together > (2) m ALTO servers could work jointly (e.g., by forming mesh/peering > among themselves). And somehow implies they are both necessary. I think federation could be achieved as long as just one of them is provided. In the first case, each AS would learn data from the integrated view of its corresponding SC. In the second case, SCs would know about other domains through what their associated ASes have received. 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
Re: [alto] Agenda requests for IETF 84
Hi Enrico, On 9 Jul 2012, at 09:50 , Enrico Marocco wrote: > if you have any requests for agenda slots at the next IETF meeting, > please send them to Vijay and me by Tuesday, July 17. As usual, priority > will be given to charter items, and to topics that have been already > presented and discussed on the list. > > In order to lower the loss probability, please send your request even if > you have already sent it before this call went out. This is a re-sending ot the request for a slot to introduce this draft: http://datatracker.ietf.org/doc/draft-xie-alto-sdn-use-cases/ 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
[alto] Fwd: New Version Notification for draft-xie-alto-sdn-use-cases-01.txt
Hi, This is a proposal on the interaction between ALTO and SDN we'd like to discuss at our next meeting in Vancouver. Comments will be extremely appreciated. Be goode, Begin forwarded message: > A new version of I-D, draft-xie-alto-sdn-use-cases-01.txt > has been successfully submitted by Haiyong Xie and posted to the > IETF repository. > > Filename: draft-xie-alto-sdn-use-cases > Revision: 01 > Title: Use Cases for ALTO with Software Defined Networks > Creation date: 2012-06-27 > WG ID: Individual Submission > Number of pages: 28 > URL: > http://www.ietf.org/internet-drafts/draft-xie-alto-sdn-use-cases-01.txt > Status: http://datatracker.ietf.org/doc/draft-xie-alto-sdn-use-cases > Htmlized:http://tools.ietf.org/html/draft-xie-alto-sdn-use-cases-01 > Diff: > http://tools.ietf.org/rfcdiff?url2=draft-xie-alto-sdn-use-cases-01 > > Abstract: > The introduction of SDN fundamentally changes the way that the ALTO > works. This draft describes the Vertical Architecture and the > Horizontal Architecture allowing coherent coexistence of application > layer traffic optimization (ALTO) with software defined network > (SDN). Unique requirements for design and operations are identified > and summarized, suggesting that the Vertical Architecture allows > better division, management, flexibility, privacy control and long- > term evolution of the network. We also define the main interactions > and information flows, and present a set of use cases to illustrate > how we extend ALTO to support SDN, in the Vertical Architecture. > > > > > The IETF Secretariat -- "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
