-----Original Message-----
From: Muhanna, Ahmad (RICH1:2H10)
Sent: Thursday, August 27, 2009 1:33 PM
To: 'Ben Campbell'
Cc: Khalil, Mohamed (RICH2:2S20); sgundave@xxxxxxxxx;
kchowdhury@xxxxxxxxxxxxxxxxxxx; pyegani@xxxxxxxxxxx; General
Area Review Team; ietf@xxxxxxxx; Jari Arkko;
marcelo@xxxxxxxxxx; 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.
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 make sense to
statically
provision that a trusted peer can remove any binding for "foo.com"?
[Ahmad]
Sure, static configuration what RFC5213 has under section 4.
However, in our case, is the peer authorized to use Global
Revocation or not. This is not restricted to a certain realm
but the restriction as mentioned above to sessions that is
hosted at the revoking mobility node.
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"?
[Ahmad]
That is the very fundamental requirement for this protocol.
Probably more than anything, it would help to discuss the sort bad
things that this authorization is intended to prevent.
[Ahmad]
Ok. We can elaborate and add some text here. Thx.
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?
[Ahmad]
Yes. For example, the client which has multiple Bindings
(referenced by different Binding IDs) could send a single
message (de-registration, a BU with lifetime zero) and
request the server (HA) to delete all bindings which belong
to this Mobile node.
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.)
[Ahmad]
Ok. I guess to close on this issue, It is fair to require
that the responder send BRA only when the (A) bit is set.
Because, also, if the initiator did not set the (A) bit, it
may very well not expecting a BRA and possibly NOT saving the
BRI as an outstanding one to start with. Thanks; will make
sure that is addressed as a global comment and will make sure
that all places are fixed.
-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.
[Ahmad]
This should be addressed as part of the authorization clarification.
-- 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"?
[Ahmad]
The valid combinations are:
Global Revocation==>>> (G) bit set and Revocation Trigger = a
Global revocation trigger.
Per-MN Revocation ==>> (G) bit cleared and Revocation Trigger
= a per-MN revocation trigger.
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.
[Ahmad]
The Global Revocation Triggers are defined under section 6.1.
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.
[Ahmad]
A good point; but in RFC3775 and RFC5213 there is no MUST for
retransmission either.
For example under section 6.9.4 of RFC5213, it says:
"
2. If the mobile access gateway fails to receive a valid matching
response for a registration or re-registration message
within the
retransmission interval, it SHOULD retransmit the
message until a
response is received.
"
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.
[Ahmad]
I believe 'SHOULD" here is to offer the implementation more
flexibility. A simple implementation could interpret 'SHOULD'
as always retransmits and moves on and still be compliant to
the specification. Others may build more complex logics which
should not be prevented.
-- 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.
[Ahmad]
Sure, thx.
-- 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?
[Ahmad]
No.
In this case, the mobile node may have registered multiple
bindings, i.e., multiple care-of addresses for the same HoA.
Each bindings is assigned one Binding ID. Let us assume that
the MN has BIDs(1, 2, 3, and 4) just for the sake of this discussion.
The home agent may send a BRI with [BIDs (1,4)], this means
ONLY BIDs (1 & 4) are being revoked. 2 & 3 still active.
The home agent may send a BRI with [BIDs (1, 2, 3, & 4)] to
revoke all of these 4 Bindings (In this case ALL Bindings).
Well, this is NOT recommended, the HA could have sent a BRI
with NO BID(s) and accomplish the same result.
-- 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.
[Ahmad]
Will fix this as pointed earlier.
-- 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"
[Ahmad]
Sure, will adopt this text.
-- 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.
[Ahmad]
Will be resolved as mentioned above.
-- 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?
[Ahmad
Will resolve as mentioned earlier above.
-- 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.
[Ahmad]
Sure, will add a note to that extent.
-- 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."
[Ahmad]
Sure. Thx.
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!
[Ahmad]
Thanks to your detailed review!
Ben.