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.
-- 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.
-- 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.
-- 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.
-- 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.
-- 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.
-- 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.
-- 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.
-- 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.
-- 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.
-- 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.
-- 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.
-- 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.
"
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf