Re: Last Call: draft-ietf-behave-nat-behavior-discovery (NATBehavior Discovery Using STUN) to Experimental RFC
On Apr 14, 2009, at 20:38 , Bruce Lowekamp wrote: > Many of the NATs out there you > can not make this determination without multiple IP addresses behind the > NAT. So you're right that you can test for a few more bizarre NAT behaviors with multiple IP addresses, but I haven't seen any evidence suggesting those behaviors are present in most NATs. In draft-jennings-behave-test-results-04.txt (google it, it's expired), you will note all the NATs where the Sec behavior is different than Prim behavior in the results table are NATs where you need more than one IP to characterize them. This includes NATs from Airlink, Cisco, Linksys, SMC, and Toshiba. Other unpublished testing has revealed it is many NATs from other vendors also work this way. Cullen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
On Jun 2, 2009, at 8:03 , Olaf Kolkman wrote: RFC4846 section 5 uses the word "recommend" If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published. Olaf, I believe this means in the contents of the document. I am under the understanding the the IESG Note in RFC is provided by the IESG not by the RFC Editor. Is there a document that says otherwise? (I'm certainly open to the possibility that perhaps these documents should not have an IESG note but that seems a different issue) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
RFC4846 section 5 uses the word "recommend" If the IESG, after completing its review, identifies issues, it may recommend explanatory or qualifying text for the RFC Editor to include in the document if it is published. Olaf, I believe this means in the contents of the document. I am under the understanding the the IESG Note in RFC is provided by the IESG not by the RFC Editor. Is there a document that says otherwise? (I'm certainly open to the possibility that perhaps these documents should not have an IESG note but that seems a different issue) My understanding of this text is that the IESG can recommend text, including an IESG Note. The RFC Editor can accept it or not. The RFC Editor has a lot of discretion here. To date, the RFC Editor has never rejected an IESG Note. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Appeal/Request for Review (was: Re: Proposed Revisions to the IETF Trust Legal Provisions (TLP))
On Aug 25, 2009, at 10:19 PM, Margaret Wasserman wrote: Hi Marshall and Bob, Could you please let us know the current status of this appeal? In the plenary in Stockholm, I understood you to say that you _do_ consider the decisions of the IAOC and the Trust to be subject to the appeals procedure, which I think is a good decision. However, it has been about 6 weeks since this appeal was sent, and I do not see a location on the IAOC/Trust web pages where the appeal text is posted, nor have I seen any response. A response is under consideration, and I have instructed the IAD and the Secretariat to prepare a place to put it, and the original appeal. Regards Marshall I think that there are several very valid points in John's appeal, and I largely agree with it. I note that the IAOC has already begun the process of bringing the minutes up to date, which I consider to be an important step. Could you help me to understand how you are reacting or responding to other portions of this appeal? Thanks, Margaret On Jul 18, 2009, at 3:38 PM, John C Klensin wrote: --On Saturday, July 18, 2009 12:55 -0400 Marshall Eubanks wrote: Hello; We (the Trustees) have received feedback on the proposed changes to the Trust Legal Provisions (TLP) and have agreed to take the following actions. Since the original call went out on the 23rd of June, the comment period is extended to the 23rd of July. ... Marshall, While I believe these changes are all improvements, I also recall several additional sets of comments on the IETF mailing list, including those that addressed the issues of: [...] Consequently, by this message to you and copy of this note to the IAOC Chair, and under the provisions of Section 3.5 of RFC 4071, I formally request that the Trustees review their actions, that the IAOC review the actions of the Trustees as part of the IASA process, and that the following actions be taken: [...] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Thanks for the detailed review and comments. Please allow me to address your comments in two parts. 1. PART-I: Major and technical issues. 2. PART-II: remaining comments. Please see answers inline for PART-I. Regards, Ahmad > -Original Message- > > Summary: This draft is on the right track, but there are open > issues. > Additionally, I have a number of editorial comments. > > Major issues: > > -- I think the security considerations need quite a bit of > work. In particular, there is very little guidance on > authorization for sending BRI messages. This seem to me have > utility for DoS attacks, particularly with the G bit set. > There is mention of reusing existing security associations if > IPSec is used--but no mention of what to do if IPSec is not > used. [Ahmad] Binding Revocation is used between two peers to revoke/terminate a mobility session(s) that have been created using an IPv6 mobility protocol signaling (Client Mobile IPv6 or Proxy MIP6). RFC3775 and RFC5213, which are the main protocols targeted by this specification, specify that "IPsec SHOULD" be used. On the other hand, there is NO other standard track specification which specify other security mechanisms to secure the IPv6 mobility signaling. Therefore, Binding Revocation specification assumes the use of whatever security mechanism that currently available to secure the IPv6 mobility signaling. > (Perhaps it is required by the underlying technology? > If so, that should be mentioned here.) [Ahmad] That is not the intention. Please see above. > You mention that > authorization is required if the G-bit is set, but go on to > say authorization details are out of scope. I think that this > draft needs to either offer much more guidance on > authentication requirements. [Ahmad] We could introduce a simple default mechanism inline with what we have in RFC5213. > It would be helpful if the > Security Considerations section discussed the consequences of > security failures, possible attacks, etc. > [Ahmad] This specification do not introduce any security threats on the top of what is being discussed in Client MIP6 and Proxy MIP6, RFC3775 and RFC5213. > > > Minor issues: > > -- S3.4.2, paragraph 1: "responds with the appropriate status > code by sending a Binding Revocation Acknowledgement message" > > Always, or just if the A bit is set? [Ahmad] This section describes the usecase when Global revocation is being used by the MAG; there is no normative text in this section. In addition, section 10.2.1. which talks about the use of the (G) bit by the MAG and indicates that whenever the (G) bit is set the (A) bit MUST be set, is correctly being referenced in this section and mentioned before the text quoted above. > > > -S4, paragraph 2: "verify that the mobile access gateway > sending the binding revocation indication message is > authorized to invoke global revocation" > > How does it make such a verification? [Ahmad] By checking the identity of the MAG if it is authorized for global revocation or not. Would a reference to section 9.2.1. makes it clearer or you think we need to add more clarification. > > -S5, second paragraph: "UDP encapsulation to traverse NATs" > > Can you include a reference for UDP encapsulation? [Ahmad] No problem. > > -- Same Paragraph: "... port numbers ... will also be used" > > Should this be normative? > > -- Same paragraph, sentence starting with "For example..." > > I don't think it's appropriate to include a normative > statement inside an "example". You could fix this by swapping > the descriptive language in the previous sentence with the > normative language in the "example". [Ahmad] Agreed. Will fix swap as suggested. Thanks. > > -- Section 7.2, last paragraph: "If a mobility node receives > a Binding Revocation Indication message with a Revocation > Trigger value that is NOT in line with the Binding Revocation > Indication message intent, e.g., the Global (G) bit set and > the Revocation Trigger field vale is a per-MN specific, the > receiving mobility node SHOULD reject the Binding Revocation > Indication message by sending a Binding Revocation > Acknowledgement message with the Status field set to > "Revocation Function NOT Supported"." > > This paragraph seems to imply some under-specification around > how to tell the Revocation Trigger value is not in line with > the initiator's intent. > > Also, do you really mean to send "... not supported"? This > really sounds like more of a "bad request" scenario. > > Did you mean to capitalize the final "NOT"? [Ahmad] I thought it was a straight forward combination. If the Global (G) bit is set, the Revocation trigger field value MUST contain one of the Global revocation triggers. If the (G) bit is cleared, the revocation trigger MUST contain a per-MN value. Any deviation, means this functionality is not supported. As far as why having "NOT" in capital letters, some drafts have the
RE: [PART-II] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Please see answers in line for PART-II. > -Original Message- > From: Ben Campbell [mailto:b...@estacado.net] > Subject: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 > > 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-mext-binding-revocation-10 > Reviewer: Ben Campbell > Review Date: 25 Aug 2009 > IESG Telechat date: 27 Aug 2009 > > Note: I was assigned to review revision 08 of this draft for > the last call ending 28 Aug, as well as this version (10) for > the 27 Aug Telechat. This review serves both purposes. > > Summary: This draft is on the right track, but there are open > issues. > Additionally, I have a number of editorial comments. > [PART-II] > > Nits/editorial comments: > > -- General: > > This draft has some significant organization issues that make > it harder to read than it needs to be. In particular, the > sections that discuss protocol details keep repeating text > that is effectively the same for each type of device. It > would be much easier to read if you did things like separate > out acknowledgement handling, race condition handling, > binding identification, retransmissions, handovers, etc into > their own sections, and have the sections on specific device > roles only discuss things specific to those devices. You have > some of the common bits separated out, but you still repeat > them over and over in the role specific sections. Not only is > this hard to read, it is prone to error. [Ahmad] Thanks. I appreciate this comment. Will make every effort to correct any error or unnecessary duplication. It may be worth noting that describing a protocol which handles the interactions of several entities and usecases that are established using different protocols is not the easiest job ever:) > > As an example, I found that this structure confused my > attempts to understand when an acknowledgement is required. > Some sections said "if the Acknowledge bit was set", but > other sections that did not mention the A bit also required > acknowledgement. [Ahmad] I think we discussed this in PART-I and will follow up on your follow-up comments after addressing all of PART-II comments. > > The sentence structure tends to be very long and wordy, with > very little punctuation. This is aggravated by the fact that > you don't make use of the acronyms and device role names once > you establish them. For example, spelling out phrases like > Binding Revocation Indication and Local Mobility Anchor every > time they are used makes for very long sentences. [Ahmad] I see what you are saying. However, we are trying to follow the style of main IP mobility protocols specifications. It seems that there are two styles for doing this. One is to always use acronyms as soon as they are established. TWO: do not use acronyms except in figures and tables, if they exist and text related to them. I personally prefer a combination of these two styles but the comments we received earlier during the development of this specification is to use one or the other:) > > Please proof read the draft again. [Ahmad] Sure. Will try again. Appreciate your effort in finding some of them; I should say many! > I found lots of missing > articles and plural/singular mismatches. I report a few of > these below, but I gave up on capturing them part way > through. The RFC editor will probably fix any of these that > get through, but if you fix it yourself, there is less danger > of the meaning being changed by edits. [Ahmad] Will do our best to catch the remaining ones. > > -- S1, paragraph 2: > > Please expand MH on first use. [Ahmad] Ok. > > "notify its local mobility anchor peer with a bulk termination" > > Does it really notify "with" a bulk termination, or "about" a > bulk termination? [Ahmad] Thx. Will use about. > > -- S3: "describe the protocol overview" > > s/describe/present [Ahmad] Ok. > > -- S3.1, paragraph 1:"the Acknowledge (A) bit is set" > > The description seems to mix the two elements--the > notification and the request for acknowledgement. It might be > easier to read and understand if you separated out a single > section on sending BRA when the A bit is set, rather than > repeating it for each scenario. > > -- Paragraph 3: "On the other hand, the mobile access gateway > usually sends a de- registration message by sending a Proxy > Binding Update with a lifetime of zero to indicate to the > local mobility anchor of the termination of the PMIPv6 mobile > node binding registration." > > Sentence logic is inverted. Suggest " ... indicate the > termination...to the local mobility anchor" This sentence > structure repeats throught the docu
RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi, Ben, > > > >> -Original Message- > >> > >> Summary: This draft is on the right track, but there are > open issues. > >> Additionally, I have a number of editorial comments. > >> > >> Major issues: > >> > >> -- I think the security considerations need quite a bit of > work. In > >> particular, there is very little guidance on authorization for > >> sending BRI messages. This seem to me have utility for DoS > attacks, > >> particularly with the G bit set. > >> There is mention of reusing existing security associations > if IPSec > >> is used--but no mention of what to do if IPSec is not used. > > [Ahmad] > > Binding Revocation is used between two peers to revoke/terminate a > > mobility session(s) that have been created using an IPv6 mobility > > protocol signaling (Client Mobile IPv6 or Proxy MIP6). RFC3775 and > > RFC5213, which are the main protocols targeted by this > specification, > > specify that "IPsec SHOULD" be used. On the other hand, there is NO > > other standard track specification which specify other security > > mechanisms to secure the IPv6 mobility signaling. > Therefore, Binding > > Revocation specification assumes the use of whatever security > > mechanism that currently available to secure the IPv6 mobility > > signaling. > > I think there are still a couple of issues here. First, Since > the underlying RFCs only specify IPSec at SHOULD strength, > this draft needs to discuss the consequences of not using it > for BRI. Depending on those consequences, it might be enough > to just warn implementors that, if you don't use IPSec, > certain bad things can happen. [Ahmad] It is NOT expected that BRI/BRA will use a different security mechanism than what is being used for securing IPv6 mobility signaling. Therefore, in order to alert implementors of the danger if IPsec is NOT used, IMO, that needs to be discussed in related IPv6 mobility specifications, e.g., RFC3775 and RFC5213, which is already there. On the other hand, it is very difficult to anticipate the criteria of other security mechanisms that would possibly be used in the future to secure IPv6 mobility signaling and consequently BRI/BRA. > OTOH, it might be that BRI has > greater security risks than for 3775/5213, and you might (for > example) need to strengthen the IPSec requirement for BRI. > > I admit to not being an expert on 3375/5213, so it may be > true that BRI is no riskier than the underlying > technology--but even if that is true I'd like to see some > discussion to support it. [Ahmad] Both IPv6 mobility signaling and BRI/BRA use the same IPv6 layer signaling. I am not sure what impact the underlying technology has on BRI./BRA that does not have on BU/BA. > > Second, I think that there is probably more guidance needed > on authorization decisions even if you do use IPSec. For > example, do you assume that any trusted peer can remove any > binding? [Ahmad] No. The revoking mobility entity revokes only those mobility session(s) which are registered with it. No mobility node can revoke a mobility session that is registered with a different trusted mobility node. > Is a trusted peer only allowed to remove bindings > that it previously established using the same SA? [Ahmad] I believe I addressed this via another comment earlier. The answer is NO. > If an SA is > torn down and a new one established, what authorization gets > inherited, if any? [Ahmad] When the SA is torn down and a new one is established, the new SA is valid for both BU/BA and BRI/BRA. In other words, the new SA will still have the same SPD which allows the BU/BA and BRI/BRA messages, etc. If your question is about authorization of Global revocation, that authorization should be done separately. > Do you assume that a peer that is trusted > to establish bindings is trusted for BRI? [Ahmad] Of course. The node which initiated or granted the registration should have the authority to revoke it. Do you see any problem there? > Do you need to > provision policies around these, and if so what are the moving parts? [Ahmad] The text under the security section was supposed to capture this. The SPD should be updated to allow MH type of 'Binding Revocation message'. If it is not enough, let us know what is missing and we can add/modify as needed. > > > > > > >> (Perhaps it is required by the underlying technology? > >> If so, that should be mentioned here.) > > [Ahmad] > > That is not the intention. Please see above. > > > >> You mention that > >> authorization is required if the G-bit is set, but go on to say > >> authorization details are out of scope. I think that this > draft needs > >> to either offer much more guidance on authentication requirements. > > [Ahmad] > > We could introduce a simple default mechanism inline with > what we have > > in RFC5213. > > It's possible that might help--can you point to the section > of 5213 you have in mind? [Ahmad] Section 4, paragraph 6. > It might a
Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
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-mext-binding-revocation-10 Reviewer: Ben Campbell Review Date: 25 Aug 2009 IESG Telechat date: 27 Aug 2009 Note: I was assigned to review revision 08 of this draft for the last call ending 28 Aug, as well as this version (10) for the 27 Aug Telechat. This review serves both purposes. Summary: This draft is on the right track, but there are open issues. Additionally, I have a number of editorial comments. Major issues: -- I think the security considerations need quite a bit of work. In particular, there is very little guidance on authorization for sending BRI messages. This seem to me have utility for DoS attacks, particularly with the G bit set. There is mention of reusing existing security associations if IPSec is used--but no mention of what to do if IPSec is not used. (Perhaps it is required by the underlying technology? If so, that should be mentioned here.) You mention that authorization is required if the G-bit is set, but go on to say authorization details are out of scope. I think that this draft needs to either offer much more guidance on authentication requirements. It would be helpful if the Security Considerations section discussed the consequences of security failures, possible attacks, etc. Minor issues: -- S3.4.2, paragraph 1: "responds with the appropriate status code by sending a Binding Revocation Acknowledgement message" Always, or just if the A bit is set? -S4, paragraph 2: "verify that the mobile access gateway sending the binding revocation indication message is authorized to invoke global revocation" How does it make such a verification? -S5, second paragraph: "UDP encapsulation to traverse NATs" Can you include a reference for UDP encapsulation? -- Same Paragraph: "... port numbers ... will also be used" Should this be normative? -- Same paragraph, sentence starting with "For example..." I don't think it's appropriate to include a normative statement inside an "example". You could fix this by swapping the descriptive language in the previous sentence with the normative language in the "example". -- Section 7.2, last paragraph: "If a mobility node receives a Binding Revocation Indication message with a Revocation Trigger value that is NOT in line with the Binding Revocation Indication message intent, e.g., the Global (G) bit set and the Revocation Trigger field vale is a per-MN specific, the receiving mobility node SHOULD reject the Binding Revocation Indication message by sending a Binding Revocation Acknowledgement message with the Status field set to "Revocation Function NOT Supported"." This paragraph seems to imply some under-specification around how to tell the Revocation Trigger value is not in line with the initiator's intent. Also, do you really mean to send "... not supported"? This really sounds like more of a "bad request" scenario. Did you mean to capitalize the final "NOT"? -- Section 7.3: RFC3775 already talks about retransmission for Binding Update messages. Does this really need to be specified separately? -- 2nd paragraph: "SHOULD retransmit" Can you offer guidance on when an implementation might reasonably not do this? (i.e. why not a MUST?) -- S8.1, 3rd para after bullets: "home agent SHOULD handle this case based on the reason for sending the Binding Revocation Indication message and its local policy" Is this entirely local policy? Is there no guidance to offer about how the "reason for sending" the BRI influences this decision? If it's really just local policy, then I'm not sure you need a normative statement (i.e. you SHOULD do whatever you choose to do...) -- Last para: "SHOULD NOT" Why not MUST NOT? -- S 10.1.1, third bullet: "MUST send a Binding Revocation Acknowledgement" So the G bit and the revocation trigger field value of "per-peer policy" is enough to require a BRA? Wouldn't this only apply when the A bit is set? (I know the initiator may have been required to set the A bit, but it seems wrong to expect the responder to infer that.) -- S 11.1, bullet 2: "SHOULD send a Binding Revocation Acknowledgement" Can you document reasons why a responder might not send the BRA, and the consequences thereof? In particular, are there scenarios where the initiator might go into retries because the responder chose not to send a BRA? -- same paragraph: "In all cases, the mobile node MUST follow Section 11.2" Do you really mean "in all cases"? This seems to contradict the SHOULD in the previous sentence, and the "If the A bit is set" condition in the first sentence in the paragraph. -- Bullet 3: "mobile node MUST send"
Re: [Gen-art] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Note that the address listed in the draft tracker for Julien bounces-- trying again with the address on the MEXT wg page: On Aug 25, 2009, at 9:56 PM, Ben Campbell wrote: 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-mext-binding-revocation-10 Reviewer: Ben Campbell Review Date: 25 Aug 2009 IESG Telechat date: 27 Aug 2009 Note: I was assigned to review revision 08 of this draft for the last call ending 28 Aug, as well as this version (10) for the 27 Aug Telechat. This review serves both purposes. Summary: This draft is on the right track, but there are open issues. Additionally, I have a number of editorial comments. Major issues: -- I think the security considerations need quite a bit of work. In particular, there is very little guidance on authorization for sending BRI messages. This seem to me have utility for DoS attacks, particularly with the G bit set. There is mention of reusing existing security associations if IPSec is used--but no mention of what to do if IPSec is not used. (Perhaps it is required by the underlying technology? If so, that should be mentioned here.) You mention that authorization is required if the G-bit is set, but go on to say authorization details are out of scope. I think that this draft needs to either offer much more guidance on authentication requirements. It would be helpful if the Security Considerations section discussed the consequences of security failures, possible attacks, etc. Minor issues: -- S3.4.2, paragraph 1: "responds with the appropriate status code by sending a Binding Revocation Acknowledgement message" Always, or just if the A bit is set? -S4, paragraph 2: "verify that the mobile access gateway sending the binding revocation indication message is authorized to invoke global revocation" How does it make such a verification? -S5, second paragraph: "UDP encapsulation to traverse NATs" Can you include a reference for UDP encapsulation? -- Same Paragraph: "... port numbers ... will also be used" Should this be normative? -- Same paragraph, sentence starting with "For example..." I don't think it's appropriate to include a normative statement inside an "example". You could fix this by swapping the descriptive language in the previous sentence with the normative language in the "example". -- Section 7.2, last paragraph: "If a mobility node receives a Binding Revocation Indication message with a Revocation Trigger value that is NOT in line with the Binding Revocation Indication message intent, e.g., the Global (G) bit set and the Revocation Trigger field vale is a per-MN specific, the receiving mobility node SHOULD reject the Binding Revocation Indication message by sending a Binding Revocation Acknowledgement message with the Status field set to "Revocation Function NOT Supported"." This paragraph seems to imply some under-specification around how to tell the Revocation Trigger value is not in line with the initiator's intent. Also, do you really mean to send "... not supported"? This really sounds like more of a "bad request" scenario. Did you mean to capitalize the final "NOT"? -- Section 7.3: RFC3775 already talks about retransmission for Binding Update messages. Does this really need to be specified separately? -- 2nd paragraph: "SHOULD retransmit" Can you offer guidance on when an implementation might reasonably not do this? (i.e. why not a MUST?) -- S8.1, 3rd para after bullets: "home agent SHOULD handle this case based on the reason for sending the Binding Revocation Indication message and its local policy" Is this entirely local policy? Is there no guidance to offer about how the "reason for sending" the BRI influences this decision? If it's really just local policy, then I'm not sure you need a normative statement (i.e. you SHOULD do whatever you choose to do...) -- Last para: "SHOULD NOT" Why not MUST NOT? -- S 10.1.1, third bullet: "MUST send a Binding Revocation Acknowledgement" So the G bit and the revocation trigger field value of "per-peer policy" is enough to require a BRA? Wouldn't this only apply when the A bit is set? (I know the initiator may have been required to set the A bit, but it seems wrong to expect the responder to infer that.) -- S 11.1, bullet 2: "SHOULD send a Binding Revocation Acknowledgement" Can you document reasons why a responder might not send the BRA, and the consequences thereof? In particular, are there scenarios where the initiator might go into retries because the responder chose not to send a BRA? -- same paragraph: "In all cases, the mobile node MUST follow Section 11.2" Do you really mean "in all cases"? T
Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
On Aug 26, 2009, at 3:58 AM, Ahmad Muhanna wrote: Hi Ben, Thanks for the detailed review and comments. Please allow me to address your comments in two parts. 1. PART-I: Major and technical issues. 2. PART-II: remaining comments. Please see answers inline for PART-I. Regards, Ahmad -Original Message- Summary: This draft is on the right track, but there are open issues. Additionally, I have a number of editorial comments. Major issues: -- I think the security considerations need quite a bit of work. In particular, there is very little guidance on authorization for sending BRI messages. This seem to me have utility for DoS attacks, particularly with the G bit set. There is mention of reusing existing security associations if IPSec is used--but no mention of what to do if IPSec is not used. [Ahmad] Binding Revocation is used between two peers to revoke/terminate a mobility session(s) that have been created using an IPv6 mobility protocol signaling (Client Mobile IPv6 or Proxy MIP6). RFC3775 and RFC5213, which are the main protocols targeted by this specification, specify that "IPsec SHOULD" be used. On the other hand, there is NO other standard track specification which specify other security mechanisms to secure the IPv6 mobility signaling. Therefore, Binding Revocation specification assumes the use of whatever security mechanism that currently available to secure the IPv6 mobility signaling. I think there are still a couple of issues here. First, Since the underlying RFCs only specify IPSec at SHOULD strength, this draft needs to discuss the consequences of not using it for BRI. Depending on those consequences, it might be enough to just warn implementors that, if you don't use IPSec, certain bad things can happen. OTOH, it might be that BRI has greater security risks than for 3775/5213, and you might (for example) need to strengthen the IPSec requirement for BRI. I admit to not being an expert on 3375/5213, so it may be true that BRI is no riskier than the underlying technology--but even if that is true I'd like to see some discussion to support it. Second, I think that there is probably more guidance needed on authorization decisions even if you do use IPSec. For example, do you assume that any trusted peer can remove any binding? Is a trusted peer only allowed to remove bindings that it previously established using the same SA? If an SA is torn down and a new one established, what authorization gets inherited, if any? Do you assume that a peer that is trusted to establish bindings is trusted for BRI? Do you need to provision policies around these, and if so what are the moving parts? (Perhaps it is required by the underlying technology? If so, that should be mentioned here.) [Ahmad] That is not the intention. Please see above. You mention that authorization is required if the G-bit is set, but go on to say authorization details are out of scope. I think that this draft needs to either offer much more guidance on authentication requirements. [Ahmad] We could introduce a simple default mechanism inline with what we have in RFC5213. It's possible that might help--can you point to the section of 5213 you have in mind? It might also be enough to have more discussion on what an implementor needs to think about to do authorization correctly. For example, does it make sense to statically provision that a trusted peer can remove any binding for "foo.com"? Is authorization policy dynamically determined by prior actions (i.e. a peer can revoke all bindings _it_ established for "foo.com", but not bindings that another device established for "foo.com"? Probably more than anything, it would help to discuss the sort bad things that this authorization is intended to prevent. It would be helpful if the Security Considerations section discussed the consequences of security failures, possible attacks, etc. [Ahmad] This specification do not introduce any security threats on the top of what is being discussed in Client MIP6 and Proxy MIP6, RFC3775 and RFC5213. That's a little hard to believe without some supporting text. Again, this could be my lack of knowledge of IPv6 mobility talking. But for example, do RFC3775 and/or 5213 already have something a mechanism for one mobility element to tell another to drop bindings in bulk? Minor issues: -- S3.4.2, paragraph 1: "responds with the appropriate status code by sending a Binding Revocation Acknowledgement message" Always, or just if the A bit is set? [Ahmad] This section describes the usecase when Global revocation is being used by the MAG; there is no normative text in this section. Understood (but I had similar questions in the normative sections). In addition, section 10.2.1. which talks about the use of the (G) bit by the MAG and indicates that whenever the (G) bit is set the (A) bit MUST be set, is correctly being referenced in this section an
Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Jari--comments inline: On Aug 26, 2009, at 5:05 AM, Jari Arkko wrote: Ben, Thanks for your review! Wrt. authorization, the document does make it clear that bulk revocation requires explicit authorization (search for "authorization"). The document does not say how to achieve this, but I would assume a global configuration flag or a list of authorized peers. We could add this to the document, if you think it helps. I think it would help. Even some non-normative examples might help. I think the most important thing is to give guidance on what the implementor needs to consider, and what sort of bad things can happen without proper authentication. When it comes to non-bulk revocation messages, I'm not sure their requirements are any different from the rest of the signaling. First, the protocol intrinsically enables only the revocation of sessions created by the two parties. Secondly, existing messages can already be used to create and delete sessions from clients -- binding revocation simply adds a capability to do that from the server side as well. Additional requirements for authorization mechanisms could be added here, but I'm not sure its needed. I think it would help to add that to the security considerations, along with some discussion on whether the ability to revoke from the server side adds any new considerations. I can accept that the answer may be "no, it doesn't", but that is easier to accept with some supporting discussion :-) Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [PART-II] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Thanks for the response. Comments inline. I will remove sections where I think we are in agreement. On Aug 27, 2009, at 3:08 AM, Ahmad Muhanna wrote: Hi Ben, Please see answers in line for PART-II. -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 [...] [PART-II] Nits/editorial comments: -- General: This draft has some significant organization issues that make it harder to read than it needs to be. In particular, the sections that discuss protocol details keep repeating text that is effectively the same for each type of device. It would be much easier to read if you did things like separate out acknowledgement handling, race condition handling, binding identification, retransmissions, handovers, etc into their own sections, and have the sections on specific device roles only discuss things specific to those devices. You have some of the common bits separated out, but you still repeat them over and over in the role specific sections. Not only is this hard to read, it is prone to error. [Ahmad] Thanks. I appreciate this comment. Will make every effort to correct any error or unnecessary duplication. It may be worth noting that describing a protocol which handles the interactions of several entities and usecases that are established using different protocols is not the easiest job ever:) I understand that, and I hope I didn't come off too critical. I know that it is very hard to make a draft that is both readable and correct, particularly when you have so many use cases that require different application behavior. As an example, I found that this structure confused my attempts to understand when an acknowledgement is required. Some sections said "if the Acknowledge bit was set", but other sections that did not mention the A bit also required acknowledgement. [Ahmad] I think we discussed this in PART-I and will follow up on your follow-up comments after addressing all of PART-II comments. Agreed. The sentence structure tends to be very long and wordy, with very little punctuation. This is aggravated by the fact that you don't make use of the acronyms and device role names once you establish them. For example, spelling out phrases like Binding Revocation Indication and Local Mobility Anchor every time they are used makes for very long sentences. [Ahmad] I see what you are saying. However, we are trying to follow the style of main IP mobility protocols specifications. It seems that there are two styles for doing this. One is to always use acronyms as soon as they are established. TWO: do not use acronyms except in figures and tables, if they exist and text related to them. I personally prefer a combination of these two styles but the comments we received earlier during the development of this specification is to use one or the other:) Okay. Believe it or not, I usually gripe about too many acronyms :-) [...] -- Same paragraph, last sentence: Do you mean "user" or "mobile node"? [Ahmad] I meant the user, because if the reason, administrative, then it probably requires the user intervention. Interesting. I assume there are cases where a typical mobile node would just quietly reestablish the binding. I gather you expect cases where it can't do so without some (possibly reconfiguration) effort on the user's part, right? It's worth thinking about whether there is some guidance you can give to implementors here. (I'm not sure there is--just something to think about.) -- S3.4.1, first paragraph, first sentence: Unclear sentence: What is doing the "hosting"? The LMA, the MAG, or the BRI message? I think you mean the MAG, but the sentence structure is ambiguous. [Ahmad] What about the following? " The local mobility anchor may send a Binding Revocation Indication message with the appropriate revocation trigger value to the mobile access gateway which hosts a specific PMIPv6 binding to indicate that the mobile node binding has been terminated and the mobile access gateway can clean up the applicable resources. s/which/that, but otherwise I think it works. " -- same paragraph: "In this case, the mobile access gateway could send a Router Advertisement message to the mobile node with the home network prefix valid lifetime set to zero." In order to accomplish what? [Ahmad] Since in PMIPv6, the MN does not participate in any mobility signaling, the mobile node is not aware that the advertised HNP is not anchored at the MAG. So, when the MAG receives a BRI for a specific binding, i.e., specific HNP binding to the current pCoA, the MAG clears associated resources; but until the mobile node receives such Router Advertisement, it wont know that it CAN not use this HNP. Okay. -S 7.1, first paragraph: "node, initiator, constructs" Confusing sentence structure. Is "initiator" a name for the sending mobil
Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Ben, Thanks for your review! Wrt. authorization, the document does make it clear that bulk revocation requires explicit authorization (search for "authorization"). The document does not say how to achieve this, but I would assume a global configuration flag or a list of authorized peers. We could add this to the document, if you think it helps. When it comes to non-bulk revocation messages, I'm not sure their requirements are any different from the rest of the signaling. First, the protocol intrinsically enables only the revocation of sessions created by the two parties. Secondly, existing messages can already be used to create and delete sessions from clients -- binding revocation simply adds a capability to do that from the server side as well. Additional requirements for authorization mechanisms could be added here, but I'm not sure its needed. Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
On 2009-08-28 03:56, Russ Housley wrote: > >>> RFC4846 section 5 uses the word "recommend" >>> If the IESG, after completing its review, identifies issues, it may >>> recommend explanatory or qualifying text for the RFC Editor to >>> include in the document if it is published. >> >> Olaf, I believe this means in the contents of the document. I am under >> the understanding the the IESG Note in RFC is provided by the IESG not >> by the RFC Editor. Is there a document that says otherwise? (I'm >> certainly open to the possibility that perhaps these documents should >> not have an IESG note but that seems a different issue) > > My understanding of this text is that the IESG can recommend text, > including an IESG Note. The RFC Editor can accept it or not. The RFC > Editor has a lot of discretion here. To date, the RFC Editor has never > rejected an IESG Note. I'm pretty sure, though, that there has been pushback and negotiation on quite a few occasions. It's important that the RFC Editor keeps this power, in the general interest of checks and balances. By the time an RFC comes out, it's too late for an appeal process to affect the outcome. So I find the current text of 3932bis completely appropriate. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-iesg-rfc3932bis (IESG Procedures for Handling of Independent and IRTF Stream Submissions) to BCP
I am under the understanding the the IESG Note in RFC is provided by the IESG not by the RFC Editor. Is there a document that says otherwise? (I'm certainly open to the possibility that perhaps these documents should not have an IESG note but that seems a different issue) My understanding of this text is that the IESG can recommend text, including an IESG Note. The RFC Editor can accept it or not. ... I'm pretty sure, though, that there has been pushback and negotiation on quite a few occasions. It's important that the RFC Editor keeps this power, in the general interest of checks and balances. +1. One can debate various details and costs about the RFC Editor function. But it really is quite useful to have the editor exert an independent review of IESG efforts to modify an RFC. Not because the IESG is suspect, but because it is deeply involved in the topics it comments on and that could cause misguided decisions. By contrast, the RFC Editor can consider suggested IESG notes with detachment. My impression, too, is that this has produced revised IESG text. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Weekly posting summary for ietf@ietf.org
Total of 92 messages in the last 7 days. script run at: Fri Aug 28 00:53:01 EDT 2009 Messages | Bytes| Who +--++--+ 10.87% | 10 | 9.03% |66650 | t...@americafree.tv 5.43% |5 | 12.67% |93479 | b...@estacado.net 5.43% |5 | 8.11% |59809 | g...@net-zen.net 3.26% |3 | 9.50% |70067 | amuha...@nortel.com 5.43% |5 | 4.73% |34908 | ietf...@comcast.net 4.35% |4 | 3.23% |23805 | do...@dougbarton.us 3.26% |3 | 3.78% |27911 | d3e...@gmail.com 3.26% |3 | 3.21% |23702 | rpellet...@isoc.org 3.26% |3 | 2.04% |15073 | jari.ar...@piuha.net 2.17% |2 | 3.11% |22962 | bernard_ab...@hotmail.com 3.26% |3 | 2.01% |14808 | joe...@bogus.com 2.17% |2 | 3.07% |22643 | lars.egg...@nokia.com 2.17% |2 | 2.05% |15147 | spen...@wonderhamster.org 2.17% |2 | 1.94% |14348 | brian.e.carpen...@gmail.com 2.17% |2 | 1.63% |12049 | nar...@us.ibm.com 2.17% |2 | 1.60% |11770 | hous...@vigilsec.com 2.17% |2 | 1.56% |11496 | flu...@cisco.com 2.17% |2 | 1.51% |11148 | hen...@levkowetz.com 2.17% |2 | 1.48% |10889 | john-i...@jck.com 2.17% |2 | 1.39% |10236 | ietf2d...@davearonson.com 2.17% |2 | 1.38% |10166 | d...@dcrocker.net 2.17% |2 | 1.37% |10125 | bra...@isi.edu 2.17% |2 | 1.16% | 8540 | paul.hoff...@vpnc.org 1.09% |1 | 1.62% |11987 | jmp...@cisco.com 1.09% |1 | 1.25% | 9254 | d...@xpasc.com 1.09% |1 | 1.19% | 8771 | ciscowo...@gmail.com 1.09% |1 | 1.14% | 8428 | lisa.dussea...@gmail.com 1.09% |1 | 0.94% | 6964 | richard.bar...@gmail.com 1.09% |1 | 0.92% | 6786 | f...@cisco.com 1.09% |1 | 0.91% | 6719 | g...@apnic.net 1.09% |1 | 0.85% | 6263 | pasi.ero...@nokia.com 1.09% |1 | 0.85% | 6262 | scott.b...@gmail.com 1.09% |1 | 0.83% | 6150 | o...@cisco.com 1.09% |1 | 0.81% | 5978 | t...@att.com 1.09% |1 | 0.81% | 5946 | ingemar.s.johans...@ericsson.com 1.09% |1 | 0.79% | 5860 | m...@lilacglade.org 1.09% |1 | 0.74% | 5436 | adr...@olddog.co.uk 1.09% |1 | 0.70% | 5193 | a...@shinkuro.com 1.09% |1 | 0.67% | 4936 | s...@resistor.net 1.09% |1 | 0.61% | 4479 | bortzme...@nic.fr 1.09% |1 | 0.59% | 4363 | li...@ohlmeier.org 1.09% |1 | 0.59% | 4319 | alexey.melni...@isode.com 1.09% |1 | 0.58% | 4251 | ev...@126.com 1.09% |1 | 0.55% | 4074 | mic...@arneill-py.sacramento.ca.us 1.09% |1 | 0.50% | 3680 | ves...@tana.it +--++--+ 100.00% | 92 |100.00% | 737830 | Total ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
