Re: [Gen-art] Gen-ART LC review of draft-ietf-isms-transport-security-model-12
I am surprised not to have seen more formal reviews of the quartet for isms I-Ds whose Last Call has just finished, updating as they do a Standard, while at the same time introducing a Transport subsystem and model, and also introducing a new (to snmp) way of providing Security. I do not know what or how these reviews are triggered but I would have expected a good deal more than this one and the one that appeared as I was drafting this response, a round dozen even. Tom Petch - Original Message - From: Ben Campbell b...@estacado.net To: i...@hardakers.net; dharring...@huawei.com; General Area Review Team gen-art@ietf.org Cc: j.schoenwael...@jacobs-university.de; i...@ietf.org Sent: Friday, April 10, 2009 10:05 PM Subject: Gen-ART LC review of draft-ietf-isms-transport-security-model-12 snip ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review of draft-ietf-isms-transport-security-model-12
On Apr 16, 2009, at 2:29 AM, Tom.Petch wrote: I am surprised not to have seen more formal reviews of the quartet for isms I-Ds whose Last Call has just finished, updating as they do a Standard, while at the same time introducing a Transport subsystem and model, and also introducing a new (to snmp) way of providing Security. I do not know what or how these reviews are triggered but I would have expected a good deal more than this one and the one that appeared as I was drafting this response, a round dozen even. Gen-art reviews are assigned to a team of volunteers (i.e. the general area review team.) I'm not sure about the assignment criteria, but I _think_ we try to catch most, if not every, draft being IETF last called for publication. Tom Petch - Original Message - From: Ben Campbell b...@estacado.net To: i...@hardakers.net; dharring...@huawei.com; General Area Review Team gen-art@ietf.org Cc: j.schoenwael...@jacobs-university.de; i...@ietf.org Sent: Friday, April 10, 2009 10:05 PM Subject: Gen-ART LC review of draft-ietf-isms-transport-security- model-12 snip ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART LC review ofdraft-ietf-isms-transport-security-model-12
Yes, every document that goes through IETF-LC is assigned one gen-art reviewer to review the document, but the gen-art review process isn't really a formal part of the IETF document process - it happens in parallel with IETF-LC and the reviews are done on behalf of the General Area director. It would not be possible for us to cover all the docs with more than one reviewer - the team is quite small. The reality (from my experience) seems to be that the only reviews you can count on during IETF-LC are those from gen-art, sec-dir (they follow a similar model as I understand it) and other areas as applicable (e.g., APP, OPS, etc.). Although some of the latter reviews often happen earlier in the process. Each of the reviews from the Gen-ART team are prefaced with a link to a Gen-ART FAQ: http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html Regards, Mary Barnes Gen-ART secretary -Original Message- From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf Of Ben Campbell Sent: Thursday, April 16, 2009 9:30 AM To: Tom.Petch Cc: General Area Review Team; i...@ietf.org Subject: Re: [Gen-art] Gen-ART LC review ofdraft-ietf-isms-transport-security-model-12 On Apr 16, 2009, at 2:29 AM, Tom.Petch wrote: I am surprised not to have seen more formal reviews of the quartet for isms I-Ds whose Last Call has just finished, updating as they do a Standard, while at the same time introducing a Transport subsystem and model, and also introducing a new (to snmp) way of providing Security. I do not know what or how these reviews are triggered but I would have expected a good deal more than this one and the one that appeared as I was drafting this response, a round dozen even. Gen-art reviews are assigned to a team of volunteers (i.e. the general area review team.) I'm not sure about the assignment criteria, but I _think_ we try to catch most, if not every, draft being IETF last called for publication. Tom Petch - Original Message - From: Ben Campbell b...@estacado.net To: i...@hardakers.net; dharring...@huawei.com; General Area Review Team gen-art@ietf.org Cc: j.schoenwael...@jacobs-university.de; i...@ietf.org Sent: Friday, April 10, 2009 10:05 PM Subject: Gen-ART LC review of draft-ietf-isms-transport-security- model-12 snip ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00
On 2009/4/13 Ralph Droms rdr...@cisco.com wrote: For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? It's even more fun than that. How do we reliably know that we are at Starbucks, and not at home? The SSID? That's not an authenticated token. Currently Windows makes security decisions based on the SSID. You could call this the best answer they could come up with for a problem with no good answers. Or you could say that it instills the user with a false sense of security. Either way, it's not something I'd be comfortable seeing in a protocol spec, so if the client is in fact to make decisions as you've suggested, we'd need a secure way of doing this. I don't know enough about WPA Enterprise to know if there's a bidirectional authentication going on there - from the UI perspective it looks like it's one-way. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00
Yup ... there is currently no way to provide authenticated, meaningful identification of the network(s) to which a host is attached. Without that identification, it's pretty hard to write any reasonable policies. - Ralph On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: On 2009/4/13 Ralph Droms rdr...@cisco.com wrote: For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? It's even more fun than that. How do we reliably know that we are at Starbucks, and not at home? The SSID? That's not an authenticated token. Currently Windows makes security decisions based on the SSID. You could call this the best answer they could come up with for a problem with no good answers. Or you could say that it instills the user with a false sense of security. Either way, it's not something I'd be comfortable seeing in a protocol spec, so if the client is in fact to make decisions as you've suggested, we'd need a secure way of doing this. I don't know enough about WPA Enterprise to know if there's a bidirectional authentication going on there - from the UI perspective it looks like it's one-way. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Gen-ART review of draft-ietf-dccp-serv-codes-08
Hi, authors, this is the only IETF last call comment I have seen. It looks like changes will be required, so I'm placing this document in the Revised ID Needed state. Lars On 2009-4-15, at 2:07, black_da...@emc.com wrote: Gorry, I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-dccp-serv-codes-08 Reviewer: David L. Black Review Date: April 14, 2009 IETF LC End Date: April 16, 2009 Summary: This draft is on the right track, but has open issues, described in the review. Comments: This draft expands the use of DCCP service codes, in essence mandating that servers dispatch to DCCP services based on service code *in addition* to server port (i.e., no longer dispatch only on server port). In addition it defines a few basic DCCP services that are useful for testing and benchmarking (e.g., chargen). All of the points noted in this review are minor, but the ones tagged below with ** are important. The problems with the security considerations text in Section 5.3 are the primary reason that the review summary is open issues rather than nits. This reviewer's expectation is that all of these points will be relatively easy to address, but they do need attention. Table of Contents needs to be regenerated - not everything is on p.4 ;-). Section 3.2: Middlebox [RFC3234] implementors therefore need to note that new DCCP connections are identified by the pair of Server Port and Service Code. Add in addition to the IP address to the end of the above sentence for clarity. ** Section 3.2: This means that the IANA may allocate a server port to more than one application. This sentence needs to be rephrased and extended, as this document does not make any changes to the way that IANA currently allocates server ports. The may above is susceptible to a misreading that this draft does change IANA server port allocation procedures for DCCP - another document would be necessary to make that change. ** Section 3.3.2 needs to be rewritten. It should be about associating the same service code with multiple ports, but the one and only sentence is about associating a port with multiple service codes. The result of the rewrite should be that associating the same service code with multiple ports is fine for both active and passive ports - the passive case is of particular importance to this draft. ** Section 5.3 needs to say something about extent of support (or lack thereof) for DCCP in IKEv2. In particular, it is important to state that IKEv2 as currently specified does not negotiate DCCP service codes. ** The last paragraph of Section 5.3 contains 2 sentences saying that this is not an issue. It is not clear what this refers to, making it impossible to determine what the issue might be. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_da...@emc.comMobile: +1 (978) 394-7754 smime.p7s Description: S/MIME cryptographic signature ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] review of draft-ietf-mpls-p2mp-te-mib-08.txt (summary)
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mpls-p2mp-te-mib-08.txt Reviewer: Francis Dupont Review Date: 2009-04-16 IETF LC End Date: 2009-04-17 IESG Telechat date: unknown Summary: Ready Regards francis.dup...@fdupont.fr PS: I'll send full comments tomorrow morning. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00
Again as I mentioned, in order to prepare or build an efficient routing policy and to select an efficient connection/interface, it would be necessary to identify, classify and/or prioritize underlying network characteristics or information of the attached networks. In addition, as many network characteristics which are essential to be used for simultaneous use of multiple interfaces are not generic forms (e.g. SSID only for 802.11), these network characteristics may require a mechanism to make them be associated with generic (formed) elements used for routing policy preparation and routing decision. Therefore, if MIF can provide an efficient guideline or mechanism for associating, it would be really amazing. I believe, the current IP network related protocols and standardized technologies may not be enough to support that on multiple interface network environment. I think each vendor, carrier, service provider and/or technology, which utilizes or supports simultaneous use of multiple connections/interfaces, may have their own proprietary mechanism in terms of gathering of network characteristics of each interface/access network technology (e.g. WiFi, GPRS, CDMA, Bluetooth, etc.), their mapping mechanism with generic formed elements, routing policy and decision mechanisms with different IP based service networks owned by different service providers or different IP network enabling core networks owned by different carriers. So, the problem Ted and Ralph are addressing seems to be just one of issues (but only for WiFi network environments) in terms of network characteristic that may be necessary to be considered during selection of an efficient connection/interface from multiple candidates. Giyeong -Original Message- From: Ralph Droms [mailto:rdr...@cisco.com] Sent: April 16, 2009 1:32 PM To: Ted Lemon Cc: Giyeong Son; Hui Deng; dhc WG; gen-art@ietf.org; mif; i...@ietf.org; black_da...@emc.com Subject: Re: [dhcwg] [mif] Gen-ART review of draft-ietf-dhc-container-00 Yup ... there is currently no way to provide authenticated, meaningful identification of the network(s) to which a host is attached. Without that identification, it's pretty hard to write any reasonable policies. - Ralph On Apr 16, 2009, at 1:26 PM 4/16/09, Ted Lemon wrote: On 2009/4/13 Ralph Droms rdr...@cisco.com wrote: For example, would a host process information received from a Starbucks network over its 802.11 interface differently from information received a home network over the 802.11 interface? It's even more fun than that. How do we reliably know that we are at Starbucks, and not at home? The SSID? That's not an authenticated token. Currently Windows makes security decisions based on the SSID. You could call this the best answer they could come up with for a problem with no good answers. Or you could say that it instills the user with a false sense of security. Either way, it's not something I'd be comfortable seeing in a protocol spec, so if the client is in fact to make decisions as you've suggested, we'd need a secure way of doing this. I don't know enough about WPA Enterprise to know if there's a bidirectional authentication going on there - from the UI perspective it looks like it's one-way. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] Request for comments regarding SEED-SRTP
Hi, Seokung. For section 2.2, I *still* think it would be good to be totally explicit as I said: Something like: - At the sender: perform step 7 before step 5. - At the receiver: perform the second half of step 5 (perform verification) after step 6. This means that authentication is performed on the cleartext rather than the ciphertext. Presumably this applies equally to SRTCP? You should say so if it is true. It occurs to me (belatedly) that this reordering apparently increases the processing that has to be done on packets before the authentication is verified, providing a greater impact for a DoS attack that modifies the encrypted payload. I think this should be noted in the security considerations (assuming I am correct). Is this a significant problem given encryption is mandatory on some packets? The other problem was fixed. Regards, Elwyn David McGrew wrote: Hi Seokung It looks like almost all of my comments were addressed. I did notice a couple things, though. The first is important, the second is very minor. There is no definition of how CCM and GCM are to be used to protect RTCP. It would not be possible to use this specification to protect RTCP packets with those algorithms. The new draft says In case of SRTCP, the Authentication Portion described in Fig.2 of [RFC3711] is treated as AAD. Is that true even if the E bit is equal zero? I suspect that what you want here is to have a definition such that, when E=0, the AAD format for SRTCP is specified differently. (Either that or a restriction to not use E=0.) In Section 2, I don't understand the meaning of and valuables and I suggest just removing the phrase. I notice that the word is still there. Perhaps variables was the intended word? Apologies for the lag in my getting this review done. Best regards, David On Apr 2, 2009, at 6:14 AM, 윤석웅 wrote: Dear David Mcgrew and Elwyn Davies. Thanks for your lots of comments during AD last call. I really appreciated it. Here is the revised draft to reflect whole your comments. Please check if thers is any problem or deficiency. If you are OK, I will submit it to proceed next step. BR, Seokung draft-ietf-avt-seed-srtp-10(alpha).txt ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Assignments for April 23, 2009 Telechat
Hi all, Here's the link to the summary of assignments for the April 23, 2009 telechat: http://www.softarmor.com/rai/temp-gen-art/reviewers-090423.html With the updated spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html For your convenience, the review boilerplate template is included below. Note that reviews should ideally be posted to the gen-art mailing list by COB on Tuesday: http://www.alvestrand.no/ietf/gen/art/review-guidelines.html Mary. --- I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: Reviewer: Review Date: IESG Telechat date: 23 April 2009 Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] A *new* batch of IETF LC reviews - 16 April 2009
Hi all, Here's the link to the new LC assignments for this week: http://www.softarmor.com/rai/temp-gen-art/reviewers-090416-lc.html The assignments are captured in the spreadsheets: http://www.softarmor.com/rai/temp-gen-art/gen-art.html http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html The standard template is included below. Thanks, Mary. --- I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: Reviewer: Review Date: IETF LC End Date: IESG Telechat date: (if known) Summary: Major issues: Minor issues: Nits/editorial comments: ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
[Gen-art] Retry: Gen-ART review of draft-ietf-tcpm-tcpsecure-11.txt
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-tcpm-tcpsecure-11.txt Reviewer: Brian Carpenter Review Date: 2009-04-17 IETF LC End Date: 2009-04-16 IESG Telechat date: 2009-04-23 Summary: Ready (minor comments) Comments: - This draft is clear and well explained. I have no comments that would block approval. The authors have agreed to the editorial comments. There's a reference in the Acknowledgements to some interoperability testing, which I understood took place about 5 years ago. This is good news since the draft changes some very basic host behaviour. I wonder whether it might not be useful for this rather special case to file an interop report, even though that is not required for PS? Editorial issues: - 6. Suggested Mitigation strengths As described in the above sections, recommendation levels for RST, SYN and DATA are tagged as SHOULD, SHOULD and MAY respectively. The reason that DATA mitigation is tagged as MAY, even though it increased the TCP robustness in general is because, the DATA injection is perceived to be more difficult (twice less unlikely) when compared to RST and SYN counterparts. Surely that should be (twice as unlikely)? less unlikely seems to be the opposite of more difficult. There is at least one occurrence of it's where the word intended is its. Randy Stewart's email address is wrong Authors need to decide whether they need the pre-RFC5378 disclaimer for any material they didn't contribute personally. == Unused Reference: 'RFC3562' is defined on line 774, but no explicit reference was found in the text___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
