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

[Ben Campbell <ben at estacado.net>]

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.