Re: An Antitrust Policy for the IETF
Based on the length of this thread, it is clear to me that more discussion is needed, but I do not think that the IETF mail list is the place to have it. So, the antitrust-policy mail list has been set up to continue the discussion. It is clear to me that many people are questioning what would go in such a policy. I have been working on a strawman. It is short, but it answers the question about what topics would be covered. I will post that strawman to the antitrust-policy mail list for discussion from two perspectives. First, does the IETF want to adopt an antitrust policy. Second, the strawman will provide the basis for a conversation on the content of such a policy if the consensus is that the IETF wants to adopt one. I'll wait a few days so that people have time to join the antitrust-policy mail list before the discussion begins. Russ On Jan 10, 2012, at 3:51 PM, IETF Secretariat wrote: A new IETF non-working group email list has been created. List address: antitrust-pol...@ietf.org Archive: http://www.ietf.org/mail-archive/web/antitrust-policy/ To subscribe: https://www.ietf.org/mailman/listinfo/antitrust-policy Purpose: Discuss the need for an antitrust or competition policy for the IETF. If the consensus is to create one, then the content of that policy will be discussed as well. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Questions about draft-betts-itu-oam-ach-code-point
Hi Adrian, I can confirm that the draft is requesting a code point for the version of G.8113.1 that was forwarded to WTSA by SG 15, this is the same as the draft that was determined in February 2011, I am not anticipating any changes prior to the approval decision at WTSA. None of the changes in G.8113.1 that were anticipated in draft-betts-itu-oam-ach-code-point-01 were implemented, I will post a new version draft-betts-itu-oam-ach-code-point to correctly reflect the content and title on G.8113.1 and respond to the other questions later this week. Regards, Malcolm Adrian Farrel adr...@olddog.co.uk 09/01/2012 12:33 PM Please respond to adr...@olddog.co.uk To draft-betts-itu-oam-ach-code-po...@tools.ietf.org, 'Huub helvoort' huub.van.helvo...@huawei.com cc m...@ietf.org, ietf@ietf.org Subject RE: Questions about draft-betts-itu-oam-ach-code-point Hi Huub and Malcolm, I recognise that the intervening month between my original email and this one included an SG15 meeting, Christmas, and New Year, but I had hoped for a response by now so that we could work out what to do with the document. In the meantime, at least my question 4 has progressed. Can you confirm that the version of G.8113.1 for which a code point is requested is that which has been sent to WTSA by SG15 (i.e., that which was determined), and that there are no plans to make any updates or revisions to that document until after it has been approved. Thanks, Adrian -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Adrian Farrel Sent: 09 December 2011 10:49 To: draft-betts-itu-oam-ach-code-po...@tools.ietf.org; 'Huub helvoort' Cc: m...@ietf.org; ietf@ietf.org Subject: Questions about draft-betts-itu-oam-ach-code-point Hi Malcolm and Huub, I have squeezed a little time from the current ITU-T meeting to look at your draft and write-up. I have also read the email threads on the IETF discussion list and the MPLS list. Sorry that this has taken me a week to process, but your publication request came at pretty much the worst possible time for getting me to do this task. I don't like proliferating threads across multiple mailing lists. On the other hand it is difficult to ensure that all the constituencies are present, so I am perpetuating the cross-posting. My review of the document... 1. idnits (http://www.ietf.org/tools/idnits/) shows a couple of nits. I think only one of these is real (the spurious space in a citation). The other nits are spurious caused by citations wrapping across lines. Could you please keep a note of the nit so that you can fix it the next time the draft is respun or so it can be captured in an RFC Editor Note at a later stage (you don't have to post a new revision to address this now unless you really want to). 2. This document requests a code point from a registry that contains code points that are used equally for MPLS LSPs and pseudowires. I can't tell from the I-D whether it is your intention that your code point would also be applicable in both cases. What is your intention? Is this obvious from G.8113.1 or does it need to be clarified? My review of the write-up and discussions... 3. There seems to be quite a feeling on the mailing lists that this document should be run through the MPLS working group. The write-up makes a case for progressing it as AD sponsored. As far as I can see, the main assertions to answer are as follows. Do you have a view on these points before I make a decision on what to do? a. This is a proposal to use an MPLS code point and so is part of MPLS by definition. b. The type of network being managed by the OAM described in G.8113.1 is an MPLS network. Therefore, this is clearly relevant to the MPLS working . Do you object to this going through the MPLS on principle, or were you just hoping to save the WG the work? If the latter, and if the WG wants to look at the draft, the easiest approach seems to be to redirect the work to the working group. 4. G.8113.1 is clearly important to understanding to which the code point is being put. Thus, an available and stable copy of group. G.8113.1 will be key to the last call review of you I-D. Can you make a stable copy available (for example, through liaison)? How does the editing work currently in progress in the SG15 meeting affect that availability? 5. Can you clarify for me why the suggested value has been suggested. This will help guide IANA who would normally do their allocation in a tidy way. Looking forward to your reply. Thanks, Adrian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: New Liaison Statement, LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN)
Support -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of ext Scott Mansfield Sent: א 08 ינואר 2012 15:53 To: ietf@ietf.org; m...@ietf.org; p...@ietf.org; cc...@ietf.org Cc: swal...@cisco.com; stbry...@cisco.com; adr...@olddog.co.uk; andrew.g.ma...@verizon.com; dbrung...@att.com Subject: FW: New Liaison Statement, LS370 - Current status ofRecommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration andMaintenance mechanism for MPLS-TP in Packet Transport Network (PTN) This is a liaison from the ITU-T SG15 WP3 providing a copy of the Determined recommendation G.8113.1 (May 2011). The liaison also provides a pointer to the internet draft draft-betts-itu-oam-ach-code-point that requests an ACh code point that is needed by G.8113.1. This is a liaison that will require a response and the ITU-T has requested a response no later than 1 August 2012. I would suggest that we use the liaison response to provide the outcome of running the IETF process required to assign the requested code point. Regards, -scott. IETF-ITU Liaison Manager for MPLS -Original Message- From: Liaison Statement Management Tool [mailto:l...@ietf.org] Sent: Sunday, January 08, 2012 3:23 AM To: ch...@ietf.org Cc: yoichi.ma...@ttc.or.jp; steve.trowbri...@alcatel-lucent.com; i...@ietf.org; l...@cisco.com; Scott Mansfield; malcolm.be...@zte.com.cn; tsbs...@itu.int; greg.jo...@itu.int; hiroshi@itu.int Subject: New Liaison Statement, LS370 - Current status of Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN) Title: LS370 - Current status of Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN) Submission Date: 2012-01-08 URL of the IETF Web page: /liaison/1125/ From: ITU-T SG 15 (Greg Jones greg.jo...@itu.int) To: The IESG (ch...@ietf.org) Cc: yoichi.ma...@ttc.or.jp,steve.trowbri...@alcatel-lucent.com,ies g...@ietf.org,l...@cisco.com,scott.mansfi...@ericsson.com Reponse Contact: tsbs...@itu.int,greg.jo...@itu.int,hiroshi@itu.int Technical Contact: malcolm.be...@zte.com.cn Purpose: For information Body: The December meeting of ITU-T Study Group 15 considered the approval of Recommendation ITU-T G.8113.1/Y.1372.1, Operations, Administration and Maintenance mechanism for MPLS-TP in Packet Transport Network (PTN). Unfortunately the Study Group could not approve this Recommendation so it was forwarded to the WTSA (20-29 November 2012) for approval. One of the issues that prevented the approval in SG 15 was the lack of an ACh code point to support this Recommendation. To resolve this issue SG 15 therefore requests the IETF to assign an ACh code point. An IETF draft draft-betts-itu-oam-ach-code-point has been submitted to request this code point. We have attached the text of the current draft of Recommendation ITU-T G.8113.1/Y.1372.1 that has been forwarded to the WTSA for approval. Attach: COM15R-22. Attachment(s): LS370 - pdf body https://datatracker.ietf.org/documents/LIAISON/file1306.pdf LS370 - pdf attachment https://datatracker.ietf.org/documents/LIAISON/file1307.pdf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-marf-redaction-04
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-marf-redaction-04 Reviewer: David L. Black Review Date: January 10, 2012 IETF LC End Date: January 18, 2011 IESG Telechat Date: January 19, 2011 Summary: This draft is on the right track but has open issues, described in the review. This draft specifies a method for redacting information from email abuse reports (e.g., hiding the local part [user] of an email address), while still allowing correlation of the redacted information across related abuse reports from the same source. The draft is short, clear, and well written. There are two open issues: [1] The first open issue is the absence of security guidance to ensure that this redaction technique effectively hides the redacted information. The redaction technique is to concatenate a secret string (called the redaction key) to the information to be redacted, apply any hashing/digest algorithm, convert the output to base64 and use that base64 string to replace the redacted information. There are two important ways in which this technique could fail to effectively hide the redacted information: - The secret string may inject insufficient entropy. - The hashing/digest algorithm may be weak. To take an extreme example, if the secret string (redaction key) consists of a single ASCII character, and a short email local part is being redacted, then the output is highly vulnerable to dictionary and brute force attacks because only 6 bits of entropy are added (the result may look secure, but it's not). Beyond this extreme example, this is a potentially real concern - e.g., applying the rule of thumb that ASCII text contains 4-5 bits of entropy per character, the example in Appendix A uses a redaction key of potatoes that injects at most 40 bits of entropy - is that sufficient for email redaction purposes? To take a silly example, if a CRC is used as the hash with that sort of short input, the result is not particularly difficult to invert. I suggest a couple of changes: 1) Change any hashing/digest algorithm to require use of a secure hash, and explain what is meant by secure hash in the security considerations section. 2) Require a minimum length of the redaction key string, and strongly suggest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). For the latter change, figure out the amount of entropy that should be used for redaction - the recommended string length will be larger because printable ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each 8-bit character, and human-written text such as this message has significantly less). From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the redaction key down to a binary key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopting it. [2] The second open issue is absence of security considerations for the redaction key. The security considerations section needs to caution that the redaction key is a secret key that must be managed and protected as a secret key. Disclosure of a redaction key removes the redaction from all reports that used that key. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. Editorial Nit: I believe that anonymization is a better description of what this draft is doing (as opposed to redaction), particularly as the result is intended to be correlatable via string match across reports from the same source. idnits 2.12.13 didn't find any nits. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-marf-redaction-04
Hi Murray, Thanks for the quick response. These are all good points. My gut reaction is to say that this is all good advice and entirely correct but probably goes a little far for the problem space we're trying to address. That sounds reasonable to me, and I like John Levine's suggestion to add material to explain more about the level of security that is appropriate for this problem space and why. In light of such an explanation, an HMAC-based mechanism could well be overkill. - make a SHOULD suggestion as to the minimum redaction key length (instead of a requirement) - make a SHOULD suggestion as to the type of hash to be used (instead of a requirement) I have a hard time believing that the examples used in the review (a as the redaction key, CRC as the hash) are ever acceptable, and for that reason, I think a couple of MUSTs would be in order to prohibit that sort of nonsense. In particular: - I think there ought to be a MUST minimum length requirement on the redaction key string to prevent really short ones. - I think use of a secure hash ought to be a MUST to prevent use of CRC and other bad ideas. That could be accompanied by additional guidance that may or may not be SHOULDs, e.g., suggest a SHA2 hash as a good secure hash, suggest use of a longer string than the minimum requirement. [2] The second open issue is absence of security considerations for the redaction key. The security considerations section needs to caution that the redaction key is a secret key that must be managed and protected as a secret key. Disclosure of a redaction key removes the redaction from all reports that used that key. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. Also a good point. I don't think this is the right place to introduce advice about key rotation and the like as those are well-discussed concepts, so instead Security Considerations can simply make reference to such material elsewhere. I'll go find some. I know there's stuff like that in RFC6376 (DKIM) but I'm sure there are better ones. That would be fine - introducing the concept of key rotation as a means to reduce the impact of key compromise accompanied by a reference to a longer explanation elsewhere seems reasonable. Thanks, --David -Original Message- From: Murray S. Kucherawy [mailto:m...@cloudmark.com] Sent: Tuesday, January 10, 2012 11:41 PM To: Black, David; i...@cybernothing.org; gen-...@ietf.org; ietf@ietf.org Cc: m...@ietf.org; presn...@qualcomm.com Subject: RE: Gen-ART review of draft-ietf-marf-redaction-04 -Original Message- From: david.bl...@emc.com [mailto:david.bl...@emc.com] Sent: Tuesday, January 10, 2012 6:44 PM To: i...@cybernothing.org; Murray S. Kucherawy; gen-...@ietf.org; ietf@ietf.org Cc: david.bl...@emc.com; m...@ietf.org; presn...@qualcomm.com Subject: Gen-ART review of draft-ietf-marf-redaction-04 Hi David, thanks for the review. [1] The first open issue is the absence of security guidance to ensure that this redaction technique effectively hides the redacted information. The redaction technique is to concatenate a secret string (called the redaction key) to the information to be redacted, apply any hashing/digest algorithm, convert the output to base64 and use that base64 string to replace the redacted information. [...] I suggest a couple of changes: 1) Change any hashing/digest algorithm to require use of a secure hash, and explain what is meant by secure hash in the security considerations section. 2) Require a minimum length of the redaction key string, and strongly suggest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). For the latter change, figure out the amount of entropy that should be used for redaction - the recommended string length will be larger because printable ASCII is not entropy-dense (at best it's good for 6 bits of entropy in each 8-bit character, and human-written text such as this message has significantly less). From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the redaction key down to a binary key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopting it. These are all good points. My gut reaction is to say that this is all good advice and entirely correct but probably goes a little far for the problem space we're trying to address. Thus, my inclination is to make the following changes (subject to WG consensus): - add all of this advice to Security
tsv-dir review of draft-ietf-mile-rfc4046-bis-05
I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-...@ietf.org if you reply to or forward this review. This draft is basically ready for publication, but has nits that should be fixed before publication. In reading this document I flagged two issues. Neither of them huge, but I'd think perhaps they should be addressed before publication. (1) The language is a little wonky in my opinion. The document is laying out a 'transport protocol'. But, while this protocol does transport bits of data this is absolutely not a layer 4 protocol and so I was initially a bit confused. This draft lays out an application layer protocol (a slightly tweaked version of HTTP to be exact). It would seem useful to me to clean this up. (2) I wondered why the document said hosts MUST use port 4590. Certainly having a well know port is useful in many cases. But, I don't see why some consortium couldn't decide they were going to use port 4545 or whatever. Likewise, when setting up a callback it'd seem straightforward to give a port number, as well. I am not sure it is the biggest deal in the world, but a solution that leveraged late binding would strikes me as more flexible and hence better. allman pgpxpchSfmM2q.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Diameter Maintenance and Extensions (dime)
Hi, During the IESG internal review of this I asked whether or not there was interest in trying to tackle end to end security for AVPs. I do know there is at least some interest in that but its not clear there's enough to warrant including it in the re-charter so I said I'd ask when the recharter went out for review... So - anyone interested in DIME solving that problem? (And willing and able to help do the work of course.) As of now, Diameter really only has hop-by-hop security which is ok in many cases but far from ideal (wearing my security hat) in some. Thanks, Stephen. On 01/11/2012 04:37 PM, IESG Secretary wrote: A modified charter has been submitted for the Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Wednesday, January 18, 2012. Diameter Maintenance and Extensions (dime) - Current Status: Active Last Modified: 2012-01-10 Chairs: Lionel Morandlionel.mor...@orange-ftgroup.com Jouni Korhonenjouni.korho...@nsn.com Operations and Management Area Directors: Dan Romascanudroma...@avaya.com Ronald Bonicarbon...@juniper.net Operations and Management Area Advisor: Dan Romascanudroma...@avaya.com Mailing Lists: General Discussion: d...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing
Re: Gen-ART review of draft-ietf-marf-redaction-04
On Jan 10, 2012, at 6:44 PM, david.bl...@emc.com david.bl...@emc.com wrote: [1] The first open issue is the absence of security guidance to ensure that this redaction technique effectively hides the redacted information. The redaction technique is to concatenate a secret string (called the redaction key) to the information to be redacted, apply any hashing/digest algorithm, convert the output to base64 and use that base64 string to replace the redacted information. There are two important ways in which this technique could fail to effectively hide the redacted information: - The secret string may inject insufficient entropy. - The hashing/digest algorithm may be weak. To take an extreme example, if the secret string (redaction key) consists of a single ASCII character, and a short email local part is being redacted, then the output is highly vulnerable to dictionary and brute force attacks because only 6 bits of entropy are added (the result may look secure, but it's not). Beyond this extreme example, this is a potentially real concern - e.g., applying the rule of thumb that ASCII text contains 4-5 bits of entropy per character, the example in Appendix A uses a redaction key of potatoes that injects at most 40 bits of entropy - is that sufficient for email redaction purposes? To take a silly example, if a CRC is used as the hash with that sort of short input, the result is not particularly difficult to invert. I suggest a couple of changes: 1) Change any hashing/digest algorithm to require use of a secure hash, and explain what is meant by secure hash in the security considerations section. Simply saying any hash algorithm listed in [FIPS180-3] is precise and sufficient. 2) Require a minimum length of the redaction key string, and strongly suggest (SHOULD) that it be randomly generated (e.g., by running sufficient output of an entropy-rich random number generator through a base64 converter). Proposal: The redaction key SHOULD be based on at least 64 bits of pseudo-random input that is converted to base64. [2] The second open issue is absence of security considerations for the redaction key. The security considerations section needs to caution that the redaction key is a secret key that must be managed and protected as a secret key. Disclosure of a redaction key removes the redaction from all reports that used that key. Agree. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. Disagree, given that we have absolutely no idea how systems that use this will work operationally. Simply telling them if it is no longer secret, you're hosed is sufficient. --Paul Hoffman ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Gen-ART review of draft-ietf-marf-redaction-04
Hi David, At 18:44 10-01-2012, david.bl...@emc.com wrote: I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please I appreciate that you have spent your time and effort in performing the review. I find the review useful. From a pure security perspective, use of HMAC with specified secure hashes (SHA2-family) and an approach of hashing the redaction key down to a binary key for HMAC would be a stronger approach. I suggest that authors consider approach, but there may be practical usage concerns that suggest not adopting it. [2] The second open issue is absence of security considerations for the redaction key. The security considerations section needs to caution that the redaction key is a secret key that must be managed and protected as a secret key. Disclosure of a redaction key removes the redaction from all reports that used that key. As part of this, guidance should be provided on when and how to change the redaction key in order to limit the effects of loss of secrecy for a single redaction key. The comments are from a security perspective. To be candid, redaction is silly as the email folks know how to get around that. The secret key does not even have to be broken; a cookie in the message would get you the information you want. The cost of preserving the secrecy is not worth it in my opinion. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
WG Review: Recharter of Diameter Maintenance and Extensions (dime)
A modified charter has been submitted for the Diameter Maintenance and Extensions (dime) working group in the Operations and Management Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by Wednesday, January 18, 2012. Diameter Maintenance and Extensions (dime) - Current Status: Active Last Modified: 2012-01-10 Chairs: Lionel Morand lionel.mor...@orange-ftgroup.com Jouni Korhonen jouni.korho...@nsn.com Operations and Management Area Directors: Dan Romascanu droma...@avaya.com Ronald Bonica rbon...@juniper.net Operations and Management Area Advisor: Dan Romascanu droma...@avaya.com Mailing Lists: General Discussion: d...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dime Archive: http://www.ietf.org/mail-archive/web/dime/current/maillist.html Description of Working Group: The Diameter Maintenance and Extensions WG will focus on maintenance and extensions to the Diameter protocol required to enable its use for authentication, authorization, accounting, charging in network access, provisioning of configuration information within the network, and for new AAA session management uses within the extensibility rules of the Diameter base protocol. The DIME working group plans to address the following items: - Maintaining and/or progressing, along the standards track, the Diameter Base protocol and Diameter Applications. This includes extensions to Diameter Base protocol that can be considered as enhanced features or bug fixes. - Diameter application design guideline. This document will provide guidelines for design of Diameter extensions. It will detail when to consider reusing an existing application and when to develop a new application. - Protocol extensions for the management of Diameter entities. This work focuses on the standardization of Management Information Bases (MIBs) to configure Diameter entities (such as the Diameter Base protocol or Diameter Credit Control nodes). The usage of other management protocols for configuring Diameter entities may be future work within the group. - Protocol extensions for bulk and grouped AAA session management. The aim of this work is to study and standardize a solution for handling groups of AAA sessions within the Diameter base protocol context. The solution would define how to identify and handle grouped AAA sessions in commands and operations. Additionally, Diameter-based systems require interoperability in order to work. The working group, along with the AD, will need to evaluate any potential extensions and require verification that the proposed extension is needed, and is within the extensibility rules of Diameter and AAA scope. Coordination with other IETF working groups and other SDOs (e.g. 3GPP) will be used to ensure this. Goals and Milestones: Done - Submit the following two Diameter Mobility documents to the IESG for consideration as a Proposed Standards:* 'Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction' * 'Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction' Done - Submit 'Diameter API' to the IESG for consideration as an Informational RFC Done - Submit 'Quality of Service Parameters for Usage with Diameter' to the IESG for consideration as a Proposed Standard. Done - Submit 'Diameter QoS Application' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Support for EAP Re-authentication Protocol' as DIME working group item Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' as DIME working group item Done - Submit 'Diameter Proxy Mobile IPv6' as DIME working group item Done - Submit 'Quality of Service Attributes for Diameter' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Proxy Mobile IPv6' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter User-Name and Realm Based Request Routing Clarifications' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter NAT Control Application' as DIME working group item Done - Submit 'Diameter Capabilities Update' as DIME working group item Done - Submit 'Diameter Credit Control Application MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Base Protocol MIB' to the IESG for consideration as an Informational RFC Done - Submit 'Diameter Capabilities Update' to the IESG for consideration as a Proposed Standard Done - Submit 'Diameter Extended NAPTR' as
Protocol Action: 'Network Configuration Protocol (NETCONF) Access Control Model' to Proposed Standard (draft-ietf-netconf-access-control-07.txt)
The IESG has approved the following document: - 'Network Configuration Protocol (NETCONF) Access Control Model' (draft-ietf-netconf-access-control-07.txt) as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netconf-access-control/ Technical Summary The standardization of network configuration interfaces for use with the NETCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF protocol access for particular users to a pre- configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. Working Group Summary There is strong consensus in the WG to publish this document. The document has been extensively discussed in the Working Group, including several WG Last Calls. The comments and reviews helped to improve the document a lot and the current version reflects the consensus of the Working Group. The Security ADs have also reviewed revision 5 of the document. The WG chairs specifically asked for a Detailed Security review, because the content of this document is all about access control and secure and properly authorized access to the NETCONF protocol and content. The last WGLC did raise only minor issues. The changes have been accepted by the WG. Document Quality Implementations of earlier drafts do (partially) exist and it is expected that NETCONF implementations will be extended once this document gets published as proposed standard. Personnel Bert Wijnen is the Document Shepherd for this document Dan Romascanu is the Responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-rmt-simple-auth-for-alc-norm-06.txt (Simple Authentication Schemes for the ALC and NORM Protocols) to Proposed Standard
The IESG has received a request from the Reliable Multicast Transport WG (rmt) to consider the following document: - 'Simple Authentication Schemes for the ALC and NORM Protocols' draft-ietf-rmt-simple-auth-for-alc-norm-06.txt as a Proposed Standard This is a second IETF Last Call initiated by a change from Experimental to Proposed Standard. The change was suggested by the IESG. 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 i...@ietf.org mailing lists by 2012-01-25. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document introduces four schemes that provide per-packet authentication, integrity and anti-replay services in the context of the ALC and NORM protocols. The first scheme is based on RSA digital signatures. The second scheme relies on the Elliptic Curve Digital Signature Algorithm (ECDSA). The third scheme relies on a group- keyed Message Authentication Code (MAC). Finally, the fourth scheme merges the digital signature and group schemes. These schemes have different target use cases and they do not all provide the same service. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-rmt-simple-auth-for-alc-norm/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-rmt-simple-auth-for-alc-norm/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
SIDR Working Group Interim Meeting February 9, 2012, San Diego, CA USA
This is to announce an interim SIDR face-to-face meeting on Thu Feb 9 following the NANOG54 meeting in San Diego, CA. The interim meeting will focus on two current SIDR topics: replay protection/beaconing and route leaks. Both topics will benefit from extended concentrated focus. Route leaks are not currently in the SIDR charter, and exploring the issues in depth is necessary before considering a future change to the charter. The venue was chosen because many of the WG comments on both topics have been about the operational impact and we might get operators to join in the discussion. The NANOG54 meeting is Mon-Wed Feb 6-8, so we will meet on Thu Feb 9 to provide an opportunity for them to attend. The agenda would be a full day meeting: 0900-1230 Replay protection - beaconing or other solutions 1230-1330 Lunch 1330-1700 Route leaks - firm definition of problem space, requirements, security concern, exposure sensitivity, remote detection, what, when, where, whether, how, who, etc., to solve this. Actual venue is planned to be at or near the NANOG54 venue. Venue and remote participation details will be announced on the SIDR mailing list. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
CORRECTED Document Action: 'A Reliable Transport Mechanism for PIM' to Experimental RFC (draft-ietf-pim-port-09.txt)
The IESG has approved the following document: - 'A Reliable Transport Mechanism for PIM' (draft-ietf-pim-port-09.txt) as an Experimental RFC This document is the product of the Protocol Independent Multicast Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pim-port/ Technical Summary This document creates a simple incremental mechanism to provide reliable PIM message delivery in PIM version 2 for use with PIM Sparse-Mode (including Source-Specific Multicast) and Bidirectional PIM. The reliable transport mechanism will be used for Join-Prune message transmission only, and can use either TCP or SCTP as the transport protocol. Working Group Summary WG progress was smooth with a large number of comments from many people helping to form the document. Document Quality This is an Experimental document. At least one implementation exists. Personnel Mike McBride (mmcbri...@gmail.com) is the Document Shepherd. Adrian Farrel (adr...@olddog.co.uk) is the Responsible AD RFC Editor Note End of 3.1: OLD: TCP Connection ID AFI: The AFI value to describe the address-family of the address of the TCP Connection ID field. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the TCP connection. NEW: TCP Connection ID AFI: The AFI value to describe the address-family of the address of the TCP Connection ID field. Note that this value does not need to match the address-family of the PIM Hello message that carries it. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the TCP connection. End of 3.2: OLD: SCTP Connection ID AFI: The AFI value to describe the address- family of the address of the SCTP Connection ID field. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the SCTP connection. NEW: SCTP Connection ID AFI: The AFI value to describe the address- family of the address of the SCTP Connection ID field. Note that this value does not need to match the address-family of the PIM Hello message that carries it. When this field is 0, a mechanism outside the scope of this document is used to obtain the addresses used to establish the SCTP connection. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
