Re: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-r

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 and mentioned before the  
> text
> quoted above.
But this text talks about how you form a BRA, not how the initiator  
formed the BRI. Would you expect a responder to just assume (without  
checking) that the A bit was set if it sees a G-bit set?
There's a lot of interaction between these bit settings that make for  
some pretty complicated state transitions. As described, it expects  
the responder to infer the A bit value based on the G-bit value. It  
would be much cleaner to to implement if it were defined so that the  
responder always sends a BRA if the A bit is set, and never if it is  
not.
As a thought experiment, how would you recommend an implementer to  
handle the case where a responder got BRI with the G bit set and the A  
bit not set? (I'm not asking for the draft to specify that--it's just  
a discussion point.)
> > -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.
Actually, this is really more of a 9.2.1 issue. (I reviewed things  
linearly.) I think a reference here would help, but note I had similar  
comments about 9.2.1 further down.
> > -S5, second paragraph: "UDP encapsulation to traverse NATs"
> >
> > Can you include a reference for UDP encapsulation?
> [Ahmad]
> No problem.
Thanks!

> > -- 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.
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.
The text indicated those as examples. Are they the only scenarios  
where the trigger value can be out of line with the "intent"? I guess  
part of my problem is that "intent" is a vague term here. The  
important thing is to make sure that all legal combinations are  
specified. I think they may be later on (again, reviewing linearly),  
but they are scattered around the draft.
> 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.
>
> > -- Section 7.3:
> >
> > RFC3775 already talks about retransmission for Binding Update
> > messages. Does this really need to be specified separately?
> [Ahmad]
> Yes. It is a separate protocol.
Okay.

> > -- 2nd paragraph: "SHOULD retransmit"
> >
> > Can you offer guidance on when an implementation might
> > reasonably not do this? (i.e. why not a MUST?)
> [Ahmad]
> Since sending a BRI message is NOT a MUST to start with, I do not
> believe that the retransmission needs to be mandated as a "MUST". A
> strong recommendation using "SHOULD" gives more flexibility to the
> initiator to retransmit based on the need and the scenario at hand. In
> addition, I did not see anywhere in RFC3775 or RFC5213 where
> retransmission is mandated.
A MUST retransmit if you don't get the ack to a BRI does not in any  
way imply MUST send a BRI.
In this case, my concern is that you have two ways to decide not to  
send a retransmission--one is that the value of BRIMaxRetriesNumber  
could be set sufficiently low (zero, I assume) to prevent  
retransmissions. The second is that the implementator could choose not  
to honor the SHOULD, even if BRIMaxRetriesNumber has a higher value.  
If you want to allow the latter, it would help to have some guidance  
(or examples) about scenarios where this would make sense, and the  
consequences of doing it.
> > -- 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...)
> [Ahmad]
> The intention here is to make sure that the home agent take in
> consideration the reason for sending the BRI, i.e., Revocation Trigger
> value and NOT to handle all of the BRI cases by applying a single
> reaction. For example, if the Revocation Trigger value indicate an
> administrative reason, then the HA probably have a lot of options for
> handling such a case. On the other hand, an inter-MAG handover
> Revocation Trigger value would probably require a more careful
> consideration.
A note to that effect would be helpful.

> > -- Last para: "SHOULD NOT"
> >
> > Why not MUST NOT?
> [Ahmad]
>
> The problem we are trying to avoid here is: if we use "MUST NOT"  
> then we
> need to specify the behavior of the receiving node in case it  
> receives a
> BRI with all of the BID(s) included. Considering such case as an error
> scenario is probably not the best way. Allowing it, then it is not  
> "MUST
> NOT" anymore.
On the contrary, it's not necessary to describe what the responder has  
to do for every possible violation of MUST level requirements by the  
initiator. But it _is_ necessary to do that for violations of SHOULD  
level requirements, because that is much more likely to happen. So by  
making this a SHOULD you've created more work on the part of the  
responder than if it were a MUST.
OTOH, if it really doesn't matter to the responder one way or another,  
then I'm not sure you need either.
BTW, It's not necessary for the responder to treat every MUST  
violation by the sender as an error--Postel's law should applies here.  
I suspect the real requirement is that the _receiver_ MUST ignore any  
BIDs if present, right?
> > -- 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.)
> [Ahmad]
> This case a little similar to the "SHOULD NOT" case above. If the (A)
> bit is NOT set, what the receiving node should do. The intention is  
> for
> the MAG (responder) in the case of (G) revocation to always send the  
> BRA
> message.
This goes back to my previous comment. You require the responder to  
make complex decisions on whether to send a BRA, based on the A-bit,  
the G-bit, the responder role, etc. It would make life much easier  
(read: less error prone) for the implementor if you could make this  
entirely dependent on a single flag.
> > -- 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?
> [Ahmad]
> Sure.
> In this bullet it says that if the mobile node receives a BRI message
> and the MN has an entry for the binding defined in the received BRI,
> then the MN MUST send a BRA. In other words, if the MN successfully
> process the BRI and still track this binding and still able to send a
> BRA, then it MUST send a BRA. In all other circumstances, e.g., the MN
> no longer tracking this binding, the MN received the BRI and before
> processing the battery went down and no BRA is sent anyway, etc. The
> whole idea is to make sure that the mandate on the mobile node is
> reasonable and within the mobile node abilities to send a BRA.
> Otherwise, we would like to offer the mobile node a reasonable excuse.
I don't think one needs to worry about scenarios such as "battery  
failed" in deciding to make a requirement a MUST or a SHOULD. If we  
did, it would not be possible to have _any_ MUSTs.
In this particular case, not sending the BRA appears to do harm, in  
that it may induce unnecessary retransmissions on the sender's part.


> > -- 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.
> [Ahmad]
> Yes. The bullet correctly reference section 11.2 which says:
>
> "
> 11.2.  Sending Binding Revocation Acknowledgement
>
>   When the mobile node receives a Binding Revocation Indication from
>   its home agent, the mobile node processes the received Binding
>   Revocation Indication as in Section 11.1.  If the mobile node is
>   required to send a Binding Revocation Acknowledgement message in
>   response to the received Binding Revocation Indication, the mobile
>   node sends a packet to its home agent containing a Binding  
> Revocation
>   Acknowledgement according to the procedure in Section 7.1 and the
>   following:
> "
>
> The key text is: "If the mobile node is required to send a BRA.." That
> requirement is defined in the bullet you reference under section 11.1.
So this is really an editorial issue then. The problem is in the  
phrase "in all cases". Putting "all cases" here, then a loophole of  
"if required" in the referenced section is confusing. I propose  
changing the sentence to say something to the effect of:
"In all cases where the MN sends a BRA, it MUST do so according to  
section 11.1"
> > -- Bullet 3: "mobile node MUST send"
> >
> > Even if A bit is not set?
> [Ahmad]
> Please see response to the comment about processing the BRI when the  
> (G)
> bit is set, as described above.
... and please see my response.

> > -- same bullet: "mobile node SHOULD send a Binding Revocation 
> > Acknowledgement with the status field set to "Binding Does NOT  
> > Exist""
> > Even if A bit is not set?
> [Ahmad]
> :)
> As you said earlier, it is inferred that is being set but if it is not
> being set, we need to specify the behavior of the MN. In this case, it
> is very important for the MN to send a BRA message and inform the HA
> that since BRI did not have the HoA IPv4 option, the MN can not  
> identify
> the impacted binding. This is to give the HA an indication that it  
> needs
> to resend BRI with the HoA IPv4 option included.
See my previous response about it being better to make explicit  
decisions on the A bit rather than inferences due to other bits. In  
this particular case, the sender has _already_ violated a MUST if it  
didn't set the A-bit. (And I assume that if it did not set the A bit,  
it probably isn't waiting for a BRA--otherwise it is doubly broken).  
Is it really that important for it to get the BRA under those  
circumstances?
> > -- Bullet 4: "MUST silently discard the Binding Revocation 
> > Indication message"
> > Even if A bit is set?
> [Ahmad]
> In other words, this is a fatal error. When the (P) bit is set, the MN
> binding is for a proxy MIPv6 binding which SHOULD never be sent to the
> MN but to a MAG. In this case, the MN should silently discard the
> message.
>
> > -- S11.1, last paragraph: "could be used by the mobile node 
> > to define what action"
> > I think this could use some more guidance, if you expect
> > consistent behavior across implementations.
> [Ahmad]
> Thanks. This probably was intentionally left like it is because, it is
> probably very difficult to get all implementations to agree on a  
> common
> behavior. However, the text was meant as a reminder to implementations
> in order to take that in consideration.
Okay.

> > -- S 11.2, 2nd bullet: "The mobile node MUST set the Status 
> > field to an appropriate value. The mobile node sets the
> > Status field to success to reflect that it has received the
> > Binding Revocation Indication and acknowledge that its IP
> > connectivity with its home agent has been revoked"
> >
> > I think this is under-specified. In particular, is the mobile
> > node allowed to set failure status values?
> [Ahmad]
> Yes, it could. E.g., if the MN received a BRI with Revocation Trigger
> value set to: a non supported value or "8  Possible Out-of Sync BCE
> State", the MN could send a BRA with status code set to failure.
Okay--I think adding a sentence or two that at least indicates that it  
sends a successful status on success, and sends an appropriate error  
status if an error occurs would help.
> > -- S 12: "BRI Maximum Number of Retries"
> >
> > Why do you have both a max number of retries _and_ a max
> > timeout? I gathered from previous sections that retries stop
> > after the backoff hits max_brack-timeout. Did I read that wrong?
> [Ahmad]
> May be the name is misleading. What the "Maximum BRA TIMEOUT" means is
> the MAX time the initiator waits before it retransmits. Here is the
> text, please let me know if you have any suggestions for modification.
>
> "
> Maximum BRA TIMEOUT (MAX_BRACK_TIMEOUT)
>
>      This variable specifies the maximum delay timeout in seconds
>      before the revoking mobility entity retransmits a BRI message.
>      The default is 2 seconds.
> "
So it's the maximum interval between any two retransmission, not the  
maximum time before retransmissions stop, right? That is, once you  
reach MAX_BRACK_TIMEOUT you stop backing-off, but you may continue to  
send retransmissions at an interval of MAX_BRACK_TIMEOUT until you  
reach max retries? If so, it might be useful to add something to the  
effect of:
"Once the interval between retransmissions reaches MAX_BRACK_TIMEOUT,  
the exponential back-off will cease. If the total number of  
retransmissions has not yet reached BRIMaxRetriesNumber, the sender  
will continue to retransmit at intervals of MAX_BRACK_TIMEOUT it does  
so."
> I will respond to the rest of the comments separately in order to make
> it easier for audience to follow.
> Many thanks again for the detailed comments.
>
> Regards,
> Ahmad
Thanks!

Ben.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf