[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf
Subject:    RE: [PART-I] Gen-ART LC and Telechat Review of
From:       "Ahmad Muhanna" <amuhanna () nortel ! com>
Date:       2009-08-29 8:21:17
Message-ID: C5A96676FCD00745B64AE42D5FCC9B6E200D4E9B () zrc2hxm0 ! corp ! nortel ! com
[Download RAW message or body]

Hi Ben,
Will address and comment on open ones. Please see inline.

Regards,
Ahmad

> -----Original Message-----
>
> Subject: Re: [PART-I] Gen-ART LC and Telechat Review of 
> draft-ietf-mext-binding-revocation-10
> 
> Hi Ahmad,
> 
> Let me comment on the security issues at a high level up 
> front, since I think I can tie together responses to several 
> of your comments below. More specific comments imbedded:
> 
> I think the email from Jari helped clarify things for me to a 
> point that I can make my concerns a little more precise. You 
> clarify further down that mobile nodes are _never_ allowed to 
> revoke bindings that weren't associated with them in the 
> first place. This actually addresses a lot of my concerns, 
> and I think it is fundamental enough to be reiterated in the 
> SecCons section.
[Ahmad]
Sure, we can make that clear.

> 
> 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.

> 
> 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.


> 
> 
> >
> >> 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:)

> 
> >
> >>
> >> Second, I think that there is probably more guidance needed on 
> >> authorization decisions even if you do use IPSec. For 
> example, do you 
> >> assume that any trusted peer can remove any binding?
> > [Ahmad]
> > No. The revoking mobility entity revokes only those mobility
> > session(s)
> > which are registered with it. No mobility node can revoke a 
> mobility 
> > session that is registered with a different trusted mobility node.
> >
> >
> >> Is a trusted peer only allowed to remove bindings that it 
> previously 
> >> established using the same SA?
> > [Ahmad]
> > I believe I addressed this via another comment earlier. The 
> answer is 
> > NO.
> >
> >> If an SA is
> >> torn down and a new one established, what authorization gets 
> >> inherited, if any?
> > [Ahmad]
> > When the SA is torn down and a new one is established, the 
> new SA is 
> > valid for both BU/BA and BRI/BRA. In other words, the new SA will 
> > still have the same SPD which allows the BU/BA and BRI/BRA 
> messages, 
> > etc. If your question is about authorization of Global revocation, 
> > that authorization should be done separately.
> 
> So it may seem obvious to you, but it's worth mentioning that 
> the node needs to make sure the new SA is with the same node 
> as the old SA.
[Ahmad]
Sure.

> 
> >
> >> Do you assume that a peer that is trusted
> >> to establish bindings is trusted for BRI?
> > [Ahmad]
> > Of course. The node which initiated or granted the 
> registration should
> > have the authority to revoke it.
> > Do you see any problem there?
> >
> >
> 
> No, if you can be sure the node is really the node you think it is.
[Ahmad]
Sure. Will tweak the text to ensure this is clear.

> 
> 
> >
> >>
> >>>
> >>>
> >>>> (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's possible that might help--can you point to the section
> >> of 5213 you have in mind?
> >
> > [Ahmad]
> > Section 4, paragraph 6.
> >
> 
> I think that would help, although it's still worth mentioning 
> that for  
> that sort of authorization to be meaningful, you have to have some  
> degree of authentication (IPSec or otherwise).
[Ahmad]
Ok.

> 
> 
> >> It might also be enough to have
> >> more discussion on what an implementor needs to think about
> >> to do authorization correctly. For example, does it make
> >> sense to statically provision that a trusted peer can remove
> >> any binding for "foo.com"?
> > [Ahmad]
> > Sure, static configuration what RFC5213 has under section 4.  
> > However, in
> > our case, is the peer authorized to use Global Revocation 
> or not. This
> > is not restricted to a certain realm but the restriction as 
> mentioned
> > above to sessions that is hosted at the revoking mobility node.
> >
> >
> >> Is authorization policy
> >> dynamically determined by prior actions (i.e. a peer can
> >> revoke all bindings _it_ established for "foo.com", but not
> >> bindings that another device established for "foo.com"?
> > [Ahmad]
> > That is the very fundamental requirement for this protocol.
> >
> 
> Okay, that helps. It's fundemental enough it might be worth  
> reiterating in the SecCons section.
[Ahmad]
No problem. Thx.

> 
> 
> >>
> >
> > [Ahmad]
> > Yes. For example, the client which has multiple Bindings 
> (referenced  
> > by
> > different Binding IDs) could send a single message 
> (de-registration, a
> > BU with lifetime zero) and request the server (HA) to delete all
> > bindings which belong to this Mobile node.
> 
> Okay, that supports the idea that BRI considerations are 
> similar those  
> for the base technologies. Does the ability for an HA to delete  
> bindings at a MN change things?
[Ahmad]
Not really.

> >>
> >>>
> >>>> -- 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.
> >>
> >> A MUST retransmit if you don't get the ack to a BRI does not in any
> >> way imply MUST send a BRI.
> > [Ahmad]
> > A good point; but in RFC3775 and RFC5213 there is no MUST for
> > retransmission either.
> > For example under section 6.9.4 of RFC5213, it says:
> >
> > "
> >   2.  If the mobile access gateway fails to receive a valid matching
> >       response for a registration or re-registration 
> message within  
> > the
> >       retransmission interval, it SHOULD retransmit the message  
> > until a
> >       response is received.
> > "
> >
> >>
> >> In this case, my concern is that you have two ways to decide not to
> >> send a retransmission--one is that the value of BRIMaxRetriesNumber
> >> could be set sufficiently low (zero, I assume) to prevent
> >> retransmissions. The second is that the implementator could
> >> choose not
> >> to honor the SHOULD, even if BRIMaxRetriesNumber has a 
> higher value.
> >> If you want to allow the latter, it would help to have 
> some guidance
> >> (or examples) about scenarios where this would make sense, and the
> >> consequences of doing it.
> >
> > [Ahmad]
> > I believe 'SHOULD" here is to offer the implementation more  
> > flexibility.
> > A simple implementation could interpret 'SHOULD' as always 
> retransmits
> > and moves on and still be compliant to the specification. Others may
> > build more complex logics which should not be prevented.
> 
> In general, SHOULDs should be used when there are specific 
> reasons you  
> think an implementation might not want to do something, not for open  
> ended flexibility. SHOULDs without additional guidance are typically  
> bad for interoperability.
> 
> 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.

> 
> >>
> >>>
> >>>>
> >>>> -- 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.
> >>
> >> On the contrary, it's not necessary to describe what the
> >> responder has
> >> to do for every possible violation of MUST level 
> requirements by the
> >> initiator. But it _is_ necessary to do that for violations 
> of SHOULD
> >> level requirements, because that is much more likely to
> >> happen. So by
> >> making this a SHOULD you've created more work on the part of the
> >> responder than if it were a MUST.
> >>
> >> OTOH, if it really doesn't matter to the responder one way or
> >> another,
> >> then I'm not sure you need either.
> >>
> >> BTW, It's not necessary for the responder to treat every MUST
> >> violation by the sender as an error--Postel's law should
> >> applies here.
> >> I suspect the real requirement is that the _receiver_ MUST
> >> ignore any
> >> BIDs if present, right?
> >
> > [Ahmad]
> > No.
> > In this case, the mobile node may have registered multiple bindings,
> > i.e., multiple care-of addresses for the same HoA. Each bindings is
> > assigned one Binding ID. Let us assume that the MN has 
> BIDs(1, 2, 3,  
> > and
> > 4) just for the sake of this discussion.
> >
> > The home agent may send a BRI with [BIDs (1,4)], this means ONLY  
> > BIDs (1
> > & 4) are being revoked. 2 & 3 still active.
> > The home agent may send a BRI with [BIDs (1, 2, 3, & 4)] to 
> revoke all
> > of these 4 Bindings (In this case ALL Bindings). Well, this is NOT
> > recommended, the HA could have sent a BRI with NO BID(s) and  
> > accomplish
> > the same result.
> 
> Okay, I think I understand now--there are two ways to delete all  
> bindings, and you are basically preferring one but not requiring it,  
> right?
[Ahmad]
True.

Many thanks one more time!

Regards,
Ahmad

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
[prev in list] [next in list] [prev in thread] [next in thread]