Hi Ahmad,
Comments inline. I deleted items I think we can consider closed.
On Aug 29, 2009, at 3:21 AM, Ahmad Muhanna wrote:
[...]
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.
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
RFCXXXX/YYYY).
[Ahmad]
We can add something similar to this. Thx.
Okay, thanks!
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.
If I use just BU/BA without IPSec, is there a way an attacker
could delete bindings in bulk without having to know all the
details for each binding?
[Ahmad]
Well, there is no mechanism with BU/BA to delete mobility sessions in
bulk as proposed in Binding Revocation; On the other hand, If BU/BA
are
used without IPsec, Operators will run out of money quickly:) and they
probably will use Global BRI/BRA (without security) to stop the
bleeding:)
Heh :-)
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? Or there
underlying architectural features that prevent or make this hard? (I
think just discussing that in the SecCon would go a long way towards
addressing my concerns.)
[...]
[...]
In this case, I'm reasonably convinced that SHOULD is okay here, but
I'd like to see some guidance around it. For example, does it make
sense to have a note indicating that an implementation might choose
not to retransmit if it either does not need reliable
delivery, or if
it has some other (preferably interoperable) reliability mechanism?
(Although one wonders why an implementation would set the A-bit but
not retransmit.)
I know that RFC3775/5213 may not do this--but I think it's
reasonable
to try to improve the way we (as the whole IETF) do things over time.
[Ahmad]
Okay. I need to see what we can do here. We probably can add some
guidance.
Okay, thanks!
[...]
Thanks!
Ben.
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf