Hi Ben, Please see inline. Regards, Ahmad > -----Original Message----- > > > > >> > >> 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. [Ahmad] Ok.
> > > >> > >> 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? [Ahmad] Well, we need to be a little careful here:) I think what you meant to say here is without any security mechanism. So, If no valid SA is being used to protect the binding revocation signaling and, I assume, the MIP6/PMIP6 signaling, then a lot of bad things could happen. > Or there > underlying architectural features that prevent or make this hard? [Ahmad] I am not quite sure what you mean by the underlying architectural features in this context. But I can say the following: If no security mechanism (SA) is being used, neither BU/BA nor BRI/BRA are allowed to be used for establishing nor revoking mobility sessions. > think just discussing that in the SecCon would go a long way towards > addressing my concerns.) [Ahmad] I am in the process of rewriting the security section and the whole draft to address all comments. Will revaluate before publishing whether we need anything specific here. Regards, Ahmad _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
