RE: [PART-I] Gen-ART LC and Telechat Review of draft-ietf-mext-binding-r

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