Samita Chakrabarti writes: 4. Should CN send a BA to MN when it receives BU with 'H' bit on ? Problem: The spec is unclear when CN should drop the packets and which cases it should return BA or BE NOTE: At Connectathon, many implementors believed that CN should respond back with rate-limitation. Some of them did say that CN should drop the BU. Supporters thought it'd be helpful for MN to know earlier so that it can correct the problem sooner. ------------------ Jari Arkko responds to Samita Chakrabarti: Section 9.5.1 of draft 21: o The Home Registration (H) bit MUST NOT be set. ... For packets carrying Binding Updates that fail to satisfy all of these tests for any reason other than insufficiency of the Sequence Number or expired nonce index values MUST be silently discarded. So, you should drop the BU. My suggestion is that no changes are needed for this. ------------------ Ed Remmell responds to Jari Arkko: Agreed. ------------------ Brian Haley responds to Jari Arkko: But what if the MN thinks we're an HA, so it sends us a BU (w/IPsec of course). In that case we would send a BA w/status 131 (Home registration not supported). When I get a BU with the H-bit set, I process it as in Section 10.3.1, when I get one withoug the H-bit set, I process it as in Section 9.5.1. This paragraph from 10.3.1 is pretty clear: o If the node implements only correspondent node functionality, or has not been configured to act as a home agent, then the node MUST reject the Binding Update. The node MUST then also return a Binding Acknowledgement to the mobile node, in which the Status field is set to 131 (home registration not supported). So which has precedence - our CN/HA configuration or the H-bit? ------------------ Jari Arkko responds to Brian Haley: Interesting. What would you propose? ------------------ Brian Haley responds to Jari Arkko: This is why I didn't understand why we put "The Home Registration (H) bit MUST NOT be set" back in 9.5.1... If the H-bit is set, we should follow 10.3.1, if not, follow 9.5.1. Of course the H-bit swap case below needs to be added too. Since our HA can also be a CN, I would propose what I just said above - tell the MN to try someone else since either we're not acting as a HA at all (code 131), or we're not one for this prefix (code 132). We will never do RR for a home binding and silently drop the packet when we see the H-bit is set. ------------------ Nicolas Delest: I was about to answer to the mailing list but looking back to the issues page that have dealt with it (issue 262, and especially 177), lets try to find a compromise between us (I think there are at least 2 supporters of each team here before proposing this eventually to the mailing list. I am one of the supporters that think a respond is needed. Here an example why: 1) MN starts RR with CN (I don't talk about CN/HA case) 2) MN sends malformed BU (*e.g.* H bit set to 1) with A bit set to 0 to CN 3) CN receives the BU and sanity check determines it is not a good BU. 4) CN drops packet. 5) MN thinks BU is OK and it starts sending packet to CN with Home address option. 6) CN will send back a BE to MN 7) MN estimates its BU was not good (though CN didn't "reject" the BU at the step 3)) When A bit is set to 1: 1) MN starts RR with CN (I don't talk about CN/HA case) 2) MN sends malformed BU (e.g. H bit set to 1) with A bit set to 1 to CN 3) CN receives the BU and sanity check determines it is not a good BU. 4) CN drops packet. 5) MN doesn't receive BA and sends a new BU 6) ditto until MAX_BINDACK_TIMEOUT 7) MN estimates its BU was not good (though CN didn't "reject" the BU) Is my analyze correct? then instead of 4) I'd prefer to see CN sends a BA status "Reason unspecified" ("Home Registration" not supported in the case of the H bit) It would avoid step 5) and 6). I considere the CN "rejects" the BU. Draft 20 allowed me to send a BA back. Yep, I know we are on draft 21 and I just noticed I can't do the same interpretation now... If fine the proposal would be Section 9.5.4: "A Binding Acknowledgement may be sent to indicate receipt of a Binding Update as follows: (*) If the Acknowledge (A) bit set is set in the Binding Update, a Binding Acknowledgement MUST be sent. Otherwise, the treatment depends on the below rule. (*) If the node rejects the Binding Update a Binding Acknowledgement MUST be sent with appropriate error status code. If the node accepts the Binding Update, the Binding Acknowledgement SHOULD NOT be sent." ------------------ Jari Arkko responds to Brian Haley: Let me try to make sure we see this the same way. The following table gives the action of a CN upon receiving a BU protected with none/RR/IPsec with H=0/1: Case Action ===================================================================== H=0, none Silent discard (missing RR) H=0, RR Process, send BA with Status=0 H=0, IPsec Silent discard (missing RR) H=1, none Silent discard (missing IPsec) H=1, RR Silent discard (missing IPsec) H=1, IPsec Process, send BA with Status=131 or 132 Is this correct or did you want some entries in a different way? Lets try to agree on this table first, then figure out the text changes necessary. ------------------ Nicolas Delest responds to Jari Arkko: Jari, when you mean missing RR, do you mean there are no Nonce indices option and the BAD option in the BU? Why not informing the MN of what is missing? If you don't inform the MN, it will keep sending the same buggy BU, instead if you inform it it could correct it. Or are we afraid of DoS attack? The table would be: Case Action ---------------------------------------------- H=0, none Send BA status "missing RR" H=0, RR Process, send BA with Status=0 H=0, IPsec Send BA status "missing RR" H=1, none Send BA status "missing IPsec" H=1, RR Send BA status "missing IPsec" H=1, IPsec Process, send BA with Status=131 or 132 Again the rationale is that we offer a way to the MN to correct itself. We inform the MN in the case 2 and 6, why not in the other cases? ------------------ Jari Arkko writes: Meeting results: Most people seem to agree with the proposed solution, i.e., requiring that RR be used if and only if H=0. And this check will be done first, and the 131 check will be done later. ------------------ Erik Nordmark writes (as a part of his IESG review): Section 9.5.1 checks the H-bit earlier and then unnecessarily talks about checking the H-bit in these paragraphs: o If the Lifetime specified in the Binding Update is nonzero and the specified care-of address is not equal to the home address for the binding, then this is a request to cache a binding for the mobile node. If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.1; otherwise, it is processed according to the procedure specified in Section 9.5.2. o If the Lifetime specified in the Binding Update is zero or the specified care-of address matches the home address for the binding, then this is a request to delete the mobile node's cached binding. In this case, the Binding Update MUST include a valid home nonce index, and the care-of nonce index MUST be ignored by the correspondent node. The generation of the binding management key depends then exclusively on the home keygen token (Section 5.2.5). If the Home Registration (H) bit is set in the Binding Update, the Binding Update is processed according to the procedure specified in Section 10.3.2; otherwise, it is processed according to the procedure specified in Section 9.5.3. ------------------ Official IETF-56 minutes: 277 - what should CN do if H=1? Proposal: Clarify that RR be used if and only if H=0, and Silent discard if RR not used as expected. No comments. Suggestion seems acceptable ------------------ Jari Arkko writes: I'm trying to close issue #277, which had to do with the behaviour of correspondent nodes and home agents when the value of the H bit does not match its expectations. The current situation in the document is that 'when RR is used' H=1 causes a silent discard. After this check there's a branch based on the value of the H bit. For H=1, a wrong prefix or non-HA receiver causes the 131/132 status codes to be sent back. For H=0 there are no further checks. There are several problems associated with this. 1) Inconsistency: If the RR MOs are present on a BU sent to a CN, IPsec was on, and H=1, Section 9.5.1 says we should silently discard the BU while Section 10.3.1 requires us to send back a 131 status code. (Counter argument: Section 10.3.1 says that Section 9.5.1 validation rules should be checked first, so the silent discard has precedence.) 2) Inconsistency: The H=0 check and the branching rules both look at the H flag and can be seen as inconsistent. (Counter argument: there's text that indicates the H=0 check is done first and the rest is done only if all checks succeed.) 3) Underspecification: 'When RR is used' does not explicitly say whether this means that the MOs in question are present, or that the receiver expects to act as a CN. 4) Debugging difficulties: Due to the silent discard, the MN does not learn that there is a problem until much later. (Counter argument 1: problem in a security MO shouldn't lead to an answer, since its likely an attack and not a bug. Counter argument 2: IPsec silently discards faulty IPsec packets, so for the home registrations we already have a silent discard behaviour on this. Still, non-security related problems should be clearly indicated back to the sender.) In IETF-56 we did not go into the details of this issue, but the proposal of using RR if and only if H=0 seemed acceptable (with silent discard if this rule is not followed). My proposal for the text to close this issue is as follows. In Section 9.5.1 change the current text: "When the return routability procedure is used to enable the establishment of nonce indices as inputs to the creation of the binding key Kbm, the following are also required: o (List of conditions) o The Home Registration (H) bit MUST NOT be set. When using Kbm for validating the Binding Update, the following are required: o (Another list of conditions)" to "When the Home Registration (H) bit is set, the following are also required: o (List of conditions) o (Another list of conditions) If the Home Registration (H) bit is not set, the Nonce Indices mobility option MUST NOT be present." Note that this approach clarifies issue 3 above. It does not solve issues 1, 2, or 4, but I think we have good couterarguments why these issues are not actual problems. ------------------ Joe Lau responds to Jari Arkko: It appears to me that you have the (H) bit backward. ------------------ Jari Arkko responds to Joe Lau: Of course. Thanks! ------------------ Samita Chakrabarti responds to Jari Arkko: Ok by me. Sorry for the late response. ------------------