RE: Last Call: draft-arkko-eap-aka-kdf (ImprovedExtensible AuthenticationProtocol Method for 3rd Generation Authentication and KeyAgreement (EAP-AKA')) to Informational RFC
Hi Jari, -Original Message- From: Jari Arkko [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 2:24 AM To: Joseph Salowey (jsalowey) Cc: Pasi Eronen; ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: Last Call: draft-arkko-eap-aka-kdf (ImprovedExtensible AuthenticationProtocol Method for 3rd Generation Authentication and KeyAgreement (EAP-AKA')) to Informational RFC Joe, First, after some discussion with some of the users of this spec from 3GPP, we have decided that AT_KDF=1 or the AKA fallback mode should be removed. AT_KDF_INPUT field values would indeed be dependent on which KDF is used. I will make the second change you suggested to fix this. [Joe] Thanks. On the network name: the client and the network execute the same algorithm to determine the network name. It has to be done by both, as otherwise we could not compare the two and the key derivation would not be very useful. There are obviously several ways in which the comparison could be carried out, transporting information in one or the other direction or both. The authors have chosen a particular model which is simple from a protocol perspective and gives more responsibility for the end host to deal with policy decisions upon a mismatch. There are different tradeoffs with other models, but I'm not necessarily convinced that they would be superior. I do note as well that centralized policy and other management tools blur the distinctions a bit. I will, however, change the text because the intent was to require that the check be always made, but allow a policy driven decision on whether to abort or to continue with a warning. [Joe]Its not clear to me that the peer will have access to the information for verification, however it seems that the server side will. This would increase the management burden on the peer. If centralized management is in place then I guess this is not as much of a problem. The management protocol can be used to provide the client with information to determine the network name and inform the server if there is a mismatch encountered on the client. It would be good to state some of these assumptions on the reliance on an external system to handle this. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-arkko-eap-aka-kdf (ImprovedExtensible AuthenticationProtocol Method for 3rd Generation Authentication and KeyAgreement (EAP-AKA')) to Informational RFC
Joe, First, after some discussion with some of the users of this spec from 3GPP, we have decided that AT_KDF=1 or the AKA fallback mode should be removed. AT_KDF_INPUT field values would indeed be dependent on which KDF is used. I will make the second change you suggested to fix this. On the network name: the client and the network execute the same algorithm to determine the network name. It has to be done by both, as otherwise we could not compare the two and the key derivation would not be very useful. There are obviously several ways in which the comparison could be carried out, transporting information in one or the other direction or both. The authors have chosen a particular model which is simple from a protocol perspective and gives more responsibility for the end host to deal with policy decisions upon a mismatch. There are different tradeoffs with other models, but I'm not necessarily convinced that they would be superior. I do note as well that centralized policy and other management tools blur the distinctions a bit. I will, however, change the text because the intent was to require that the check be always made, but allow a policy driven decision on whether to abort or to continue with a warning. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Workshop on ROADM, Part of Globecom 2008
*Register before October 30 and take advantage of reduced registration rate * *The Ninth International Workshop on Optical Networking Technologies (IWONT) * *ROADMs: Components, Systems, and Networks* *Sunday, November 30, 2008, 2:00-5:00 pm** * ** *(Part of Globecom 2008, New Orleans , USA ) * * * The Reconfigurable Optical Add/Drop Multiplexer (ROADM) is an important building block of next-generation optical networks. Recent progress in optical device and system technologies enabled cost-effective realization of innovative agile ROADM architectures. These architectures are highly desirable today for service provider networks. Both telecommunication service providers (Telcos) and Cable Multiple System Operators (MSOs) are utilizing ROADMs to face the increasing growth of broadband-access and the demand for triple-play (delivery of voice, data, and video to end customer). In this workshop, we discuss the role of ROADMs in service providers' networks. We examine new technologies and systems which are emerging today and investigate the impact of these systems on service providers' network architectures, operation, and management. *The Program:* *1) Brandon Collins (JDSU, USA), ROADMs in Today's and Tomorrow's Optical Networks* *2) Peter Peng (Alcatel-Lucent, USA), The Recipe for Zero-Touch Photonics Networks: ROADMs, TOADM, and ORGS (Other Really Good STUFF)* *3) Kuniaki Motoshima (Mitsubishi Electric Corporation, Japan), Optical and System technologies for 10 Gbps x 80 ROADM systems* *4) David Gutierrez (Fujitsu, USA), OAMP Considerations in DWDM ROADM Deployments* *5) Young Lee (Hauwei, USA), Modeling and Encoding of ROADM-based Switch in Wavelength Switched Optical Networks (WSON)* *6) Al-Sukhni (University of Ottawa, Canada), Availability-Guaranteed Distributed Provisioning Framework for Differentiated Protection Services in Optical Mesh Networks* ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
I agree that (a) is where ALTO should focus. To elaborate a bit, (a) can only be provided by the ISP by definition (nobody else really knows the ISP's network and business policies), while (b) and (c) are, if I understand you correctly, both currently being done using internal communications within the p2p applications using their existing protocols. IMO, standardizing (a) is very important because it allows ISPs to provide information to applications that that they can't otherwise get (e.g. ISP policies) or can only derive in complex, inaccurate ways (e.g. using hop counts to approximate network locality). - Laird Popkin, CTO, Pando Networks mobile: 646/465-0570 - Original Message - From: Lisa Dusseault [EMAIL PROTECTED] To: Vijay K. Gurbani [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], ietf@ietf.org Sent: Wednesday, October 15, 2008 2:39:57 PM (GMT-0500) America/New_York Subject: Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto) On Wed, Oct 15, 2008 at 8:20 AM, Vijay K. Gurbani [EMAIL PROTECTED] wrote: Narayanan, Vidya wrote: Peer selection is important to ISPs from a network utilization perspective and to peers themselves from a performance perspective. That automatically makes peer selection a function of multiple aspects - a) information that some service providers may decide to share with the peers, b) information that peers decide to make available about themselves to other peers for this purpose, and, c) any measurements peers may do on their own. The current charter definition (and from what I can tell based on your response below) only seems to allow for a). I would agree that c) is out of scope of ALTO and something that peers can additionally do. I strongly believe that b) should be part of the ALTO work. I believe that incorporating (b) expands the charter quite a bit, whereas the consensus since the first BoF was for narrowing it down. I will also note that the feedback expressed on the list does not appear to view ALTO as a peer description protocol. To be sure, I am not unsympathetic to (b), it seems like a great problem to solve, it's just that ALTO may not be the best place to solve this problem. In the end, maybe the ADs can decide a way forward. There's plenty of work to do in a). My recommendation based on estimation of appropriate scope as well as an estimation of the consensus here, would be to do that first -- to have a charter that is scoped to (a). Then the possibilities for (b) include working in the P2P research group, individual submissions, and /or a new BoF/WG. Another option would be a future charter update for ALTO if it's successful and there's consensus for it to be the basis for (b). Lisa ___ p2pi mailing list [EMAIL PROTECTED] https://www.ietf.org/mailman/listinfo/p2pi___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)
Citing one of the responses from Vijay on Oct 13 For instance, it is not ALTO that gets to decide which peer is hosting which content and what the contributions of that peer to the overlay are. However, it is ALTO's job to provide information to a querying peer allowing it to determine wisely where it will download the content from. I agree ALTO does not determine content location but given a set of content locations by an application would provide a ranked order of good peers to download this from. However, a fundamental issue to consider is that simply using ISP information is not enough for a querying peer to determine wisely what to do. Unless there is a performance perspective to the goodness of peers, is there a real incentive for applications to adopt looking up ALTO since they anyway need to do a bunch of performance measurements. Applications typically may be happy simply saturating download bandwidth and not much else. Providing more information in ALTO could be a path to incentivising the users of the service. What this more information is should be up for debate. We should also consider the more general question of when we are designing something for peer selection we are only designing a small piece of an information plane for the Internet. In this context, it may be useful to have information that can be aggregated across various applications and simply because specific BitTorrent clients may implement some such mechanisms does not mean that is a good design choice to leave it out of ALTO. An information plane (see the U Wash IPlane paper) of some kind may be something to consider given that we seem to solving only one part of the puzzle. Instead of each application building their own proprietary and application-specific information plane which is redundant and wasteful, such an information plane could potentially be something ALTO provides and can be reused across a wide range of services. Thanks, Saumitra Das ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
BCP 142, RFC 5382 on NAT Behavioral Requirements for TCP
A new Request for Comments is now available in online RFC libraries. BCP 142 RFC 5382 Title: NAT Behavioral Requirements for TCP Author: S. Guha, Ed., K. Biswas, B. Ford, S. Sivakumar, P. Srisuresh Status: Best Current Practice Date: October 2008 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 31 Characters: 50306 See Also: BCP0142 I-D Tag:draft-ietf-behave-tcp-08.txt URL:http://www.rfc-editor.org/rfc/rfc5382.txt This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a product of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-daboo-imap-annotatemore (IMAP METADATA Extension) to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'IMAP METADATA Extension ' draft-daboo-imap-annotatemore-15.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the [EMAIL PROTECTED] mailing lists by 2008-11-13. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. This version has substantive simplifications relative to a previous version that went through IETF last call. The file can be obtained via http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-15.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_iddTag=8469rfc_flag=0 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
