RE: Followup on Gen-ART review of draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10)
Thank you Ben for reviewing and taking the time to go through the document once more! Agreed; Sorry, I missed that one. I will make sure it is included in the next revision. I am sure you are okay not to spin another revision unless this is the only outstanding comment. Thanks again! Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@nostrum.com] Sent: Friday, October 02, 2009 2:47 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; kchowdh...@starentnetworks.com; pyeg...@juniper.net; General Area Review Team; IETF-Discussion list; Jari Arkko; marc...@it.uc3m.es; Julien Laganier Subject: Followup on Gen-ART review of draft-ietf-mext-binding-revocation (was Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10) Hi, This is a followup of my Gen-ART review of draft-ietf-mext-binding- revocation, updated based on revision 13 of that draft. This revision addresses all of my substantive issues, and most of the editorial issues. I had one outstanding minor editorial comment where the author proposed a specific change, but that change did not make it into revision 13 as far as I can tell: -- Section 11, (InitMINDelayBRIs) (I think I commented on this, but can't find the resolution) Did you intend for the _default_ to be a range (between .5 and 1 sec), or did you mean to say the default was 1 second, and it must not be configured to less than .5 seconds? I suspect the latter, but it's not clear from the text. [Ahmad] Sure, will fix this as follows: Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) This variable specifies the initial delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 1 second but not to be configured less than 0.5 seconds. Revision 13 still appears to have the old text. Thanks! Ben. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [DISCUSS + Gen-ART] Review of draft-ietf-mext-binding-revocation-10
Hello All, We have submitted a new revision (13) of the Binding Revocation draft which addresses all comments including Ben and Ralph outstanding ones. In summary, we did the following: 1. After some discussion, we removed the Acknowledge (A) bit but maintained the same logic. 2. We also simplified the structure of the document to eliminate duplication and moved all common text under The Initiator and Responder sections. 3. For simplification, added new terminology: Initiator and Responder. 4. Defined a new Error Code Proxy Binding Revocation NOT Supported to allow the mobile node to reject a BRI with the (P) bit is set. Please take a look and let us know if you still have any comments or you are satisfied with the way your comments have been addressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1 3.txt Many thanks in advance! Regards, Ahmad -Original Message- From: Muhanna, Ahmad (RICH1:2H10) Sent: Wednesday, September 16, 2009 5:34 PM To: 'Ben Campbell' Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ben, Not at all. I just thought that would work better for you. But, I am okay with keeping the text and adding the note. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Wednesday, September 16, 2009 5:32 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ahmad, I guess that's okay since the removed text talks about behavior under an error condition anyway, so I won't object further if you do it this way. But I actually prefer the old text with the warning about retransmissions. My concern is, the proposal below simply leaves the case of A being set but having no matching binding undefined. I think that makes implementors even more likely to decide not to send a BRA in that case. Is the warning about retransmissions causing concern? On Sep 16, 2009, at 5:19 PM, Ahmad Muhanna wrote: Hello Ben, Thinking about this a little more, I think that you also would accept if we remove the text causing grief all together:) In other words, what about if we reword the text as below: OLD TEXT: = o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement, the mobile node MUST do so according to Section 10.2. NEW TEXT: = o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. This way we do not need to add the clarification note. What do you think? Please let me know and many thanks again! Regards, Ahmad -Original Message- From: Muhanna, Ahmad (RICH1:2H10) Sent: Monday, September 14, 2009 2:06 PM To: 'Ben Campbell' Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ben, I am fine with your proposed text. Many thanks for your review and comments. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Monday, September 14, 2009 2:02 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ahmad, Please see inline for my suggested text for the retransmission issue. Otherwise, I agree this closes the open issues. Thanks! Ben. On Sep 12, 2009, at 3:23 AM, Ahmad Muhanna wrote: Hi Ben, Hopefully we can close on all of the open issues. Please see inline. Regards, Ahmad
RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hello Ben, Thinking about this a little more, I think that you also would accept if we remove the text causing grief all together:) In other words, what about if we reword the text as below: OLD TEXT: = o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement, the mobile node MUST do so according to Section 10.2. NEW TEXT: = o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. This way we do not need to add the clarification note. What do you think? Please let me know and many thanks again! Regards, Ahmad -Original Message- From: Muhanna, Ahmad (RICH1:2H10) Sent: Monday, September 14, 2009 2:06 PM To: 'Ben Campbell' Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ben, I am fine with your proposed text. Many thanks for your review and comments. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Monday, September 14, 2009 2:02 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ahmad, Please see inline for my suggested text for the retransmission issue. Otherwise, I agree this closes the open issues. Thanks! Ben. On Sep 12, 2009, at 3:23 AM, Ahmad Muhanna wrote: Hi Ben, Hopefully we can close on all of the open issues. Please see inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 This is a followup on revision 12, since it came out before I got to revision 11: Overall, I think this revision is much better. Most of my concerns have been addressed, but I have a few minor ones remaining. Specific comments: -- Section 10.1, 2nd bullet: I don't think we resolved my concern about the SHOULD in the last sentence. To recap, I think that needs to either be a MUST, or the draft should offer guidance about the reasoning for the SHOULD and the consequences of not following it. I'm picking on this one in particular because it seems like not sending a BRA when the A bit was set is likely to cause retransmissions on the part of the initiator. [Ahmad] If the MN does NOT have a binding in its BUL for the HoA address that is included in the Type 2 Routing header, the mobile node should not respond back (that was specifically discussed in details on the wg ml). It is like instructing the MN to delete a session that does not exist. Although, the (A) bit is set, it is up to the mobile node whether to send a BRA or not. I do not believe we need to mandate that via a MUST. I am sure some handset vendors will not like that at all. Did the work group consider that if a MN doesn't respond, it can expect to get a bunch of retransmissions--each of which it will need to parse, check for bindings, etc.; possibly eating more resources than responding in the first place would have? I could understand if the concern was that the MN might get irrelevant (or even malicious) BRIs from arbitrary sources, but since they should only be arriving from trusted peers over established SAs, I find the choice surprising. But in any case, my concern was that it should be a MUST _or_ it should have discussion of the consequences of not doing it. A line or two mentioning why this is a should, under what circumstances it makes sense to not respond, and most importantly pointing out the potential for needless retransmission would help. [Ahmad] Yes we discussed that, but there are cases when the MN is not able to send a BRA, for example, losing coverage, etc. SHOULD still a very strong requirement, the node MUST do it unless there is a very good valid reason not to. But, please see below. Also, the last sentence does
RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Not at all. I just thought that would work better for you. But, I am okay with keeping the text and adding the note. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Wednesday, September 16, 2009 5:32 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ahmad, I guess that's okay since the removed text talks about behavior under an error condition anyway, so I won't object further if you do it this way. But I actually prefer the old text with the warning about retransmissions. My concern is, the proposal below simply leaves the case of A being set but having no matching binding undefined. I think that makes implementors even more likely to decide not to send a BRA in that case. Is the warning about retransmissions causing concern? On Sep 16, 2009, at 5:19 PM, Ahmad Muhanna wrote: Hello Ben, Thinking about this a little more, I think that you also would accept if we remove the text causing grief all together:) In other words, what about if we reword the text as below: OLD TEXT: = o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement, the mobile node MUST do so according to Section 10.2. NEW TEXT: = o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. This way we do not need to add the clarification note. What do you think? Please let me know and many thanks again! Regards, Ahmad -Original Message- From: Muhanna, Ahmad (RICH1:2H10) Sent: Monday, September 14, 2009 2:06 PM To: 'Ben Campbell' Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ben, I am fine with your proposed text. Many thanks for your review and comments. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Monday, September 14, 2009 2:02 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ahmad, Please see inline for my suggested text for the retransmission issue. Otherwise, I agree this closes the open issues. Thanks! Ben. On Sep 12, 2009, at 3:23 AM, Ahmad Muhanna wrote: Hi Ben, Hopefully we can close on all of the open issues. Please see inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 This is a followup on revision 12, since it came out before I got to revision 11: Overall, I think this revision is much better. Most of my concerns have been addressed, but I have a few minor ones remaining. Specific comments: -- Section 10.1, 2nd bullet: I don't think we resolved my concern about the SHOULD in the last sentence. To recap, I think that needs to either be a MUST, or the draft should offer guidance about the reasoning for the SHOULD and the consequences of not following it. I'm picking on this one in particular because it seems like not sending a BRA when the A bit was set is likely to cause retransmissions on the part of the initiator. [Ahmad] If the MN does NOT have a binding in its BUL for the HoA address that is included in the Type 2 Routing header, the mobile node should not respond back (that was specifically discussed in details on the wg ml). It is like instructing the MN to delete a session that does not exist. Although, the (A) bit is set, it is up to the mobile node whether to send a BRA or not. I do not believe we need to mandate that via a MUST. I am sure some handset vendors will not like that at all. Did the work group consider that if a MN
RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, I am fine with your proposed text. Many thanks for your review and comments. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Sent: Monday, September 14, 2009 2:02 PM To: Muhanna, Ahmad (RICH1:2H10) Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ahmad, Please see inline for my suggested text for the retransmission issue. Otherwise, I agree this closes the open issues. Thanks! Ben. On Sep 12, 2009, at 3:23 AM, Ahmad Muhanna wrote: Hi Ben, Hopefully we can close on all of the open issues. Please see inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 This is a followup on revision 12, since it came out before I got to revision 11: Overall, I think this revision is much better. Most of my concerns have been addressed, but I have a few minor ones remaining. Specific comments: -- Section 10.1, 2nd bullet: I don't think we resolved my concern about the SHOULD in the last sentence. To recap, I think that needs to either be a MUST, or the draft should offer guidance about the reasoning for the SHOULD and the consequences of not following it. I'm picking on this one in particular because it seems like not sending a BRA when the A bit was set is likely to cause retransmissions on the part of the initiator. [Ahmad] If the MN does NOT have a binding in its BUL for the HoA address that is included in the Type 2 Routing header, the mobile node should not respond back (that was specifically discussed in details on the wg ml). It is like instructing the MN to delete a session that does not exist. Although, the (A) bit is set, it is up to the mobile node whether to send a BRA or not. I do not believe we need to mandate that via a MUST. I am sure some handset vendors will not like that at all. Did the work group consider that if a MN doesn't respond, it can expect to get a bunch of retransmissions--each of which it will need to parse, check for bindings, etc.; possibly eating more resources than responding in the first place would have? I could understand if the concern was that the MN might get irrelevant (or even malicious) BRIs from arbitrary sources, but since they should only be arriving from trusted peers over established SAs, I find the choice surprising. But in any case, my concern was that it should be a MUST _or_ it should have discussion of the consequences of not doing it. A line or two mentioning why this is a should, under what circumstances it makes sense to not respond, and most importantly pointing out the potential for needless retransmission would help. [Ahmad] Yes we discussed that, but there are cases when the MN is not able to send a BRA, for example, losing coverage, etc. SHOULD still a very strong requirement, the node MUST do it unless there is a very good valid reason not to. But, please see below. Also, the last sentence does not seem to make grammatical sense after the edits. Thx, here is the new text, please let me know if you are okay with it. o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement following Section 10.2. That's better, depending on the resolution of the SHOULD discussion above. [Ahmad] Here is the text with the proposed addition as suggested above: o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement following Section 10.2. In the case when the MN does not send a BRA message in response to a BRI with the Acknowledge (A) bit is set, the MN may receive a retransmit of the BRI message. Is that acceptable? Mostly. I would say one or more retransmissions, as they are likely to get several. Also, keep in mind this causes additional work for the initiator, who would have
RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Hopefully we can close on all of the open issues. Please see inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 This is a followup on revision 12, since it came out before I got to revision 11: Overall, I think this revision is much better. Most of my concerns have been addressed, but I have a few minor ones remaining. Specific comments: -- Section 10.1, 2nd bullet: I don't think we resolved my concern about the SHOULD in the last sentence. To recap, I think that needs to either be a MUST, or the draft should offer guidance about the reasoning for the SHOULD and the consequences of not following it. I'm picking on this one in particular because it seems like not sending a BRA when the A bit was set is likely to cause retransmissions on the part of the initiator. [Ahmad] If the MN does NOT have a binding in its BUL for the HoA address that is included in the Type 2 Routing header, the mobile node should not respond back (that was specifically discussed in details on the wg ml). It is like instructing the MN to delete a session that does not exist. Although, the (A) bit is set, it is up to the mobile node whether to send a BRA or not. I do not believe we need to mandate that via a MUST. I am sure some handset vendors will not like that at all. Did the work group consider that if a MN doesn't respond, it can expect to get a bunch of retransmissions--each of which it will need to parse, check for bindings, etc.; possibly eating more resources than responding in the first place would have? I could understand if the concern was that the MN might get irrelevant (or even malicious) BRIs from arbitrary sources, but since they should only be arriving from trusted peers over established SAs, I find the choice surprising. But in any case, my concern was that it should be a MUST _or_ it should have discussion of the consequences of not doing it. A line or two mentioning why this is a should, under what circumstances it makes sense to not respond, and most importantly pointing out the potential for needless retransmission would help. [Ahmad] Yes we discussed that, but there are cases when the MN is not able to send a BRA, for example, losing coverage, etc. SHOULD still a very strong requirement, the node MUST do it unless there is a very good valid reason not to. But, please see below. Also, the last sentence does not seem to make grammatical sense after the edits. Thx, here is the new text, please let me know if you are okay with it. o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement following Section 10.2. That's better, depending on the resolution of the SHOULD discussion above. [Ahmad] Here is the text with the proposed addition as suggested above: o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement following Section 10.2. In the case when the MN does not send a BRA message in response to a BRI with the Acknowledge (A) bit is set, the MN may receive a retransmit of the BRI message. Is that acceptable? -- Same section, 4th bullet: This one still seems to ignore the A bit value. Given the other edits, am I correct in assuming that you expect a BRA if the A bit was set, otherwise a silent discard? [Ahmad] I believe we discussed this a little before. It is a fatal error and the MN should never receive a BRI with the (P) bit set. That why this behavior is the same regardless of the (A) bit is set or not. If you feel that some clarification about the (A) bit needs to be added, I can say, .. regardless if the Acknowledge (A) bit is set or not, the mobile node MUST silently discard the BRI message. From previous discussion, I thought we had converged on the idea that the A-bit should always be authoritative, rather than having the A-bit treatment change due to context. Again, my concern is that the sender is likely to retransmit multiple times if you don't respond. [Ahmad] Yes, the (A) bit is authoritative when it is
RE: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Thanks for the follow up. Please see answers inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 This is a followup on revision 12, since it came out before I got to revision 11: Overall, I think this revision is much better. Most of my concerns have been addressed, but I have a few minor ones remaining. Specific comments: -- Section 10.1, 2nd bullet: I don't think we resolved my concern about the SHOULD in the last sentence. To recap, I think that needs to either be a MUST, or the draft should offer guidance about the reasoning for the SHOULD and the consequences of not following it. I'm picking on this one in particular because it seems like not sending a BRA when the A bit was set is likely to cause retransmissions on the part of the initiator. [Ahmad] If the MN does NOT have a binding in its BUL for the HoA address that is included in the Type 2 Routing header, the mobile node should not respond back (that was specifically discussed in details on the wg ml). It is like instructing the MN to delete a session that does not exist. Although, the (A) bit is set, it is up to the mobile node whether to send a BRA or not. I do not believe we need to mandate that via a MUST. I am sure some handset vendors will not like that at all. Also, the last sentence does not seem to make grammatical sense after the edits. Thx, here is the new text, please let me know if you are okay with it. o If the Acknowledge (A) bit is set in the Binding Revocation Indication and its Binding Update List contains an entry for the IP address in the Type 2 routing header, the mobile node MUST send a Binding Revocation Acknowledgement. However, in all other cases when the Acknowledge (A) bit is set in the BRI, the mobile node SHOULD sends a Binding Revocation Acknowledgement following Section 10.2. -- Same section, 4th bullet: This one still seems to ignore the A bit value. Given the other edits, am I correct in assuming that you expect a BRA if the A bit was set, otherwise a silent discard? [Ahmad] I believe we discussed this a little before. It is a fatal error and the MN should never receive a BRI with the (P) bit set. That why this behavior is the same regardless of the (A) bit is set or not. If you feel that some clarification about the (A) bit needs to be added, I can say, .. regardless if the Acknowledge (A) bit is set or not, the mobile node MUST silently discard the BRI message. -- Section 11, (InitMINDelayBRIs) (I think I commented on this, but can't find the resolution) Did you intend for the _default_ to be a range (between .5 and 1 sec), or did you mean to say the default was 1 second, and it must not be configured to less than .5 seconds? I suspect the latter, but it's not clear from the text. [Ahmad] Sure, will fix this as follows: Initial Minimum Delay Between BRI messages (InitMINDelayBRIs) This variable specifies the initial delay timeout in seconds before the revoking mobility entity retransmits a BRI message. The default is 1 second but not to be configured less than 0.5 seconds. -- Security Considerations: I think there is enough potential for confusion about when IPSec is required to put some non-normative description of when it is and isn't required, along with references to the normative requirements. [Ahmad] I suppose this is just a comment that does not need clarification or anything like that. Thanks again Ben for your review and comments! Thanks! Ben. On Sep 5, 2009, at 3:04 AM, Ahmad Muhanna wrote: Hello, We have updated the draft to address all comments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation -1 1.txt In summary, here is a list of the major changes: 1. Enhanced to the security text mainly under section 6.1. and section 13 (Security Considerations) to address Ben comments. In addition, we eliminated the Security Model section based on Ralph's comment. 2. Enhanced the text for MAG authorization and defined a default mechanism as specified under section 13, Security Considerations. 3. Addressed Pasi's comments by adding text to clearly specify that the current specification uses mobile node identifier option, MN-ID, with subtype 1, as stated mainly under section 5.1. In addition, we defined the format of wild card NAI as per the use of this specification, text under section 8.1.1. 4. Addressed all the remaining of Ralph's detailed comments in several places of the document. 5. Clarified that the responder sends BRA only if the Acknowledge (A) bit is set. Text was tweaked in several places. 6. all nits and editorial comments Please let me know
Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hello, We have updated the draft to address all comments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-binding-revocation-1 1.txt In summary, here is a list of the major changes: 1. Enhanced to the security text mainly under section 6.1. and section 13 (Security Considerations) to address Ben comments. In addition, we eliminated the Security Model section based on Ralph's comment. 2. Enhanced the text for MAG authorization and defined a default mechanism as specified under section 13, Security Considerations. 3. Addressed Pasi's comments by adding text to clearly specify that the current specification uses mobile node identifier option, MN-ID, with subtype 1, as stated mainly under section 5.1. In addition, we defined the format of wild card NAI as per the use of this specification, text under section 8.1.1. 4. Addressed all the remaining of Ralph's detailed comments in several places of the document. 5. Clarified that the responder sends BRA only if the Acknowledge (A) bit is set. Text was tweaked in several places. 6. all nits and editorial comments Please let me know if you still have any issue. Thanks for all of your comments and help! Regards, Ahmad -Original Message- From: Muhanna, Ahmad (RICH1:2H10) Sent: Thursday, August 27, 2009 1:33 PM To: 'Ben Campbell' Cc: Khalil, Mohamed (RICH2:2S20); sgund...@cisco.com; kchowdh...@starentnetworks.com; pyeg...@juniper.net; General Area Review Team; ietf@ietf.org; Jari Arkko; marc...@it.uc3m.es; Laganier, Julien Subject: 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.
RE: [PART-II] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
-- S7.2, paragraph 2: Since some mobility entities, e.g., local mobility anchor and mobile access gateway, are allowed to receive and possibly send a Binding Revocation Indication or Binding Revocation Acknowledgement for different cases, therefore, if IPsec is used to secure signaling between the local mobility anchor and mobile access gateway, it prevents any of them from processing a Binding Revocation message that was not constructed by an authorized party. I have trouble parsing this sentence. (You did not respond to this one.) [Ahmad] We basically wanted to say that since the MAG and LMA are both allowed to send BRI and receive BRA, IPsec will enable the peer to detect if a man in the middle, for example, reflected a BRI message that it has initiated back to the peer and consequently silently drop that BRI message. In the broader sense, we wanted to say that IPsec enables any of the peers to detect if the received BRI is coming from an unauthorized party and consequently ignore without processing it. I hope we got it right:) I think if you replace the .. allowed to receive and possibly send a Binding Revocation Indication or Binding Revocation Acknowledgement for different cases with ...allowed to send BRI and receive BRA, it would be easier to read. [Ahmad] Sure, makes sense. Thanks again for all the comments. Hopefully will get a new revision before the end of the week. Regards, Ahmad ___ 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, Please see inline. Regards, Ahmad -Original Message- I still have concerns about the use of IPSec, though, as without IPSec of some other form of authentication, an attacker could conceivably impersonate the node that bindings were associated with. This is particularly bothersome in use cases that allow a node to revoke bindings without having to know the details of each individual binding, such as the G-bit, or an included NAI of the form @example.com. I'm not saying that this draft needs to make IPSec into a MUST. [Ahmad] If it comes to me, I am comfortably fine with that:) But it is appropriate for it to point out that if you _don't_ use it, bad things could happen. (See my comment on that point further down.) It may be that using MIPv6 without IPSec is just as bad without BRI as with it--in which case it's fair to say that any attacks enabled by not using IPSec with BRI are no worse than using the base technologies without BRI. (Such statements are easier to believe with some discussion to support them, though :-) ) [Ahmad] When IPsec is used, the only issue that we identified that needs special attention was the Global Revocation with Revocation Trigger value Per-Peer Policy when sent from the MAG [because it deletes all sessions between the two peers]. Although, some people still disagreed that there is no great risk in there and no special treatment should take place. At any rate, since this message coming from a peer in the visited network, we wanted the home network to have the upper hand and be able to give specific privileges to peers in the different visited networks, i.e., MAGs. What this means? the ability to establish an IPsec SA between the MAG and the LMA does not give the MAG the automatic privilege to use Global Revocation with Revocation Trigger value of per-Peer Policy. That why we required authorization. Again, I'm looking for discussion on what the impact of choosing _not_ to use IPSec, since it is only required at a SHOULD strength. I think the answer to the similar point below helps. [Ahmad] Ok. More inline: On Aug 27, 2009, at 1:32 PM, Ahmad Muhanna wrote: 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. Sure--but it's appropriate for the BRI spec to say If BRI is used without IPSec, these bad things can happen in addition to the bad things that might happen if you use the base technology without IPSec. Or alternatively, The bad things that can happen with BRI without IPSec are functionally identical to those for the base technology, so the IPSec related security considerations are identical to those in RFC/). [Ahmad] We can add something similar to this. Thx. Okay, thanks! OTOH, it might
RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Please see inline. Regards, Ahmad -Original Message- From: Ben Campbell [mailto:b...@estacado.net] Subject: Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 On Sep 1, 2009, at 3:35 PM, Ahmad Muhanna wrote: [...] So is it true that using bulk revocation without IPSec could make it possible for an attacker to masquerade as an authorized party, and delete large numbers of bindings with a single BRI? [Ahmad] Well, we need to be a little careful here:) I think what you meant to say here is without any security mechanism. In particular, without an authentication mechanism. So, If no valid SA is being used to protect the binding revocation signaling and, I assume, the MIP6/PMIP6 signaling, then a lot of bad things could happen. Right, and those bad things seem at least slightly worse with BRI than without it, due to the bulk revocation mechanism--so additional mention seems appropriate. [Ahmad] Will try to address this in the new revision. Hopefully, this week. Or there underlying architectural features that prevent or make this hard? [Ahmad] I am not quite sure what you mean by the underlying architectural features in this context. But I can say the following: If no security mechanism (SA) is being used, neither BU/BA nor BRI/BRA are allowed to be used for establishing nor revoking mobility sessions. Hmm--maybe this is all some confusion on my part. Somewhere I got the impression the requirement to use IPSec for BU messages was SHOULD strength. But in rereading RFC3775, I see it at MUST strength. But I am then confused by the language in this draft that says If IPSec is used... So, to close on this--do you consider the _use_ of IPSec for BRI to be a SHOULD or MUST? If it's a MUST, then I withdraw my comments about what happens if you don't use IPSec?, and apologize for the confusion. [Ahmad] As you mentioned, RFC3775 mandates the use of IPsec to protect BU/BA between the MN and the HA. However, RFC5213, Proxy Mobile IPv6, mandates the implementation of IPsec on the MAG and LMA. So, as you see it is not straight forward:) On the other hand, I understand what you are trying to say. Let me work with the authors on this and will share the security related text before publishing. I am sure we can come up with a text that reasonably address your concern while staying within the wg consensus. think just discussing that in the SecCon would go a long way towards addressing my concerns.) [Ahmad] I am in the process of rewriting the security section and the whole draft to address all comments. Will revaluate before publishing whether we need anything specific here. Okay. Thanks! Ben. ___ 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
Hi, Ben, Sorry for the late reply, hope to close on all comments; please see inline. -Original Message- [...] [PART-II] Nits/editorial comments: -- General: 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. [Ahmad] Not at all. I thank you much for the thorough review and comments! -- 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.) [Ahmad] Probably we can allow it to be applicable to the user and mobile node. What about if we just state This mechanism enables the user or the mobile node to react .. -- 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. [Ahmad] Ok. -S 7.1, first paragraph: node, initiator, constructs Confusing sentence structure. Is initiator a name for the sending mobility node? If so, it would help to use it later [Ahmad] Sure. Will remove it. Actually, I meant to propose you keep it, so that you could simplify later sentences. For example, you could substitute The initiatior for The mobility node that sends a Binding Revocation Indication message. [Ahmad] Ok. (the next paragraph uses the same structure again.) -- 2nd paragraph: In the BRI message, the initiator MUST set the Sequence Number field to the next sequence number available for Binding Revocation Does this conflict with the section 6.1 statement that it could be random [Ahmad] I do not see a conflict with sec 6.1. If the sequence random is set using a random generator, then the next sequence number is random too. I think there is some danger that an implementor will be confused by the words sequence and next for something that is not necessarily sequential. I gather you don't care how the implementation selects this number as long as there are no collisions, right? [Ahmad] Yes. It might be helpful to have a sentence or two that say that--as it could be random doesn't fully explain that you expect this to be local policy. [Ahmad] Sure. More importantly, this implies a requirement that the responder MUST NOT attempt to infer meaning from the sequence numbers--for example, out-of-sequence numbers are meaningless. [Ahmad] True. The use of the sequence number is to enable the initiator to match the BRA with the outstanding associated BRI. Since the chance of having more than one outstanding BRI, we MUST make sure that there is no collision. Also, if an implementation chose to use sequential values, does it have to worry about rollovers? [Ahmad] No. Does the potential guess-ability of a sequence number have security implications? [Ahmad] Not at all. Packet must pass IPsec authentication first. -- Same Paragraph: Since sending Binding Revocation Indication message is not done on a regular basis, a 16 bit sequence number field is large enough to allow the initiator to match the Binding Revocation Acknowledgement to the outstanding Binding Revocation Indication with Acknowledge (A) bit set using the sequence number field only. Sentence is hard to follow. I suggest separating the idea that you can match BRAs to BRIs with a 16 bit sequence number from the idea that you only get a BRA if the BRI had it's A bit set. [Ahmad] Sure. What about the following: Since sending Binding Revocation Indication message is not done on a regular basis, a 16 bit sequence number field is large enough to allow the initiator to match the Binding Revocation Acknowledgement to its outstanding Binding Revocation Indication that had the Acknowledge (A) bit set. Actually, I think the point would be clearer if you dropped the part about the A bit
RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10
Hi Ben, Will address and comment on open ones. Please see inline. Regards, Ahmad -Original Message- Subject: Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-revocation-10 Hi Ahmad, Let me comment on the security issues at a high level up front, since I think I can tie together responses to several of your comments below. More specific comments imbedded: I think the email from Jari helped clarify things for me to a point that I can make my concerns a little more precise. You clarify further down that mobile nodes are _never_ allowed to revoke bindings that weren't associated with them in the first place. This actually addresses a lot of my concerns, and I think it is fundamental enough to be reiterated in the SecCons section. [Ahmad] Sure, we can make that clear. I still have concerns about the use of IPSec, though, as without IPSec of some other form of authentication, an attacker could conceivably impersonate the node that bindings were associated with. This is particularly bothersome in use cases that allow a node to revoke bindings without having to know the details of each individual binding, such as the G-bit, or an included NAI of the form @example.com. I'm not saying that this draft needs to make IPSec into a MUST. [Ahmad] If it comes to me, I am comfortably fine with that:) But it is appropriate for it to point out that if you _don't_ use it, bad things could happen. (See my comment on that point further down.) It may be that using MIPv6 without IPSec is just as bad without BRI as with it--in which case it's fair to say that any attacks enabled by not using IPSec with BRI are no worse than using the base technologies without BRI. (Such statements are easier to believe with some discussion to support them, though :-) ) [Ahmad] When IPsec is used, the only issue that we identified that needs special attention was the Global Revocation with Revocation Trigger value Per-Peer Policy when sent from the MAG [because it deletes all sessions between the two peers]. Although, some people still disagreed that there is no great risk in there and no special treatment should take place. At any rate, since this message coming from a peer in the visited network, we wanted the home network to have the upper hand and be able to give specific privileges to peers in the different visited networks, i.e., MAGs. What this means? the ability to establish an IPsec SA between the MAG and the LMA does not give the MAG the automatic privilege to use Global Revocation with Revocation Trigger value of per-Peer Policy. That why we required authorization. More inline: On Aug 27, 2009, at 1:32 PM, Ahmad Muhanna wrote: 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. Sure--but it's appropriate for the BRI spec to say If BRI is used without IPSec
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 whole cause value in capital letters, but it is also meant to say that this is a bad request. --
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 document. While the inverted form is not technically wrong, it's difficult to read (for me, anyway). --
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 also be enough to have more discussion on what an implementor needs to think about to do authorization correctly. For example, does it
Looking for a social ticket
Hi, If anyone have an extra social event ticket, please respond to me directly. Thanks in advance! Regards, Ahmad ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
