[Mobopts] Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt

Hi James,

thanks for your additional comments.  My responses are inline.

>>> Section 4.2, 3rd & 4th para: I've never been convinced that a
>>> mobile node would want to keep optimized routes hot while it was
>>> in dormant mode, and this example doesn't convince me either.
>>> Route optimization helps with RTT latency, and such latency is an
>>> issue primarily in real time traffic. The example given here, a
>>> messaging server (presumably IM), is a store and forward system
>>> that will derive little benefit from keeping routes hot during
>>> optimization. Even for real time traffic, like VoIP, the CN still
>>> has to do SIP signaling to initiate the connection, and while
>>> there is some amount of urgency to the signaling above a store
>>> and forward application, it still is not going to suffer if the
>>> traffic is routed through the home agent. The latency involved in
>>> initiating the IP connection with the dormant mode mobile node
>>> through paging is likely to exceed any benefit from keeping
>>> optimized routes hot.
>>
>> Should we remove the example and say instead that it be worthwhile
>> to save the wireless bandwidth?
>
> Yes, I think that should be enough.

Ok, this is done.

>>> Section 5, para 1: Are the tradeoffs between universal
>>> applicablity v.s. efficiency discussed in this paper anywhere?
>>> This would be the ideal paper to have the discussion.
>>
>> It's mentioned where pre-configuration is discussed, for instance.
>
> Might be good to give it a more prominant place, perhaps up front. It
> is a good architectural point, that should not get lost in the
> details of the various techniques.

Yes, that's true.  I added the following section to the Introduction
section:

++++
    This paper describes, classifies, and evaluates strategies that can
    enhance or optimize Mobile IPv6 route optimization.  These
    optimizations have different objectives:  Some of them tackle
    signaling latency or overhead, while others focus on security
    improvements.  Again others seek to increase protocol robustness or
    to add to the functionality of base Mobile IPv6.  When it comes to
    evaluating a particular optimization, it is important to not only
    regard its relative improvement over standard Mobile IPv6, but to
    also consider the optimization's costs in terms of hardware upgrades,
    software modifications, and manual configuration, as well as its
    applicability to different scenarios and ease of deployment.  E.g.,
    end-to-end techniques like Mobile IPv6 route optimization itself have
    a natural lower bound with respect to signaling latency of one round-
    trip time.  (It takes the first one-way time to signal a new care-of
    address to a peer; the second one-way time is needed by the first
    packet to arrive at the new care-of address.)  To reduce the latency
    below one round-trip time, some optimizations make use of network
    infrastructure.  While the benefit of such infrastructure can be
    enormous, the associated acquisition and maintenance costs are a
    disadvantage that needs to be kept in mind.  Also, infrastructure-
    based optimizations are ineffective when the infrastructure is
    unavailable.  (This may, e.g., be the case when a mobile node
    switches to a different administrative domain.)  Though end-to-end
    optimizations are slower, they are usually cheaper and easier to
    deploy, and they are operable without network support.
++++

>>> Section 5.5, para 2: Later in the paper, you discuss this, but
>>> the statistical uniqueness properties of CGAs suggest that the
>>> care-of test might not be needed since the probability of another
>>> node having exactly the same interface identifier is fairly low.
>>> I think you should state that here. It is the same tradeoff that
>>> optimistic DAD makes. The argument you advance later in the paper
>>> that the attacker can still mount an attack on the subnet is
>>> irrelevent. An attacker can do that without using route
>>> optimization, by creating a zombie and programming it to iterate
>>> through non-existant addresses in the victim subnet.
>>
>> I think there is still an issue with CGAs and RO of which one needs
>> to be aware:
>>
>> An attacker could use any interface identifier in order to bomb a
>> certain network.  The only thing that matters in such a case is the
>>  network prefix.
>>
>> Route optimization does not create the issue with flooding, but it
>> can aggravate it.  You get amplification without programming a
>> zombie and distributing viral software.  And if you choose to
>> program a zombie nonetheless, the zombie can misuse route
>> optimization for you. (In the latter case, the zombie would contact
>> a large set of powerful correspondent nodes, download large files,
>> and redirect those files to the target network.  This is "more
>> efficient" compared to when the zombie alone sends packets.)
>>
>
>
> OK, so it sounds as if RO using CGA w.o. an RR test will provide
> additional leverage to an attacker, right? Perhaps you could explain
> this a little more in the draft?

I added the following two paragraphs to section "Mobility-Related
Security Threats :: Flooding Attacks":

++++
    Note that a redirection-based flooding attack can be combined with
    the conventional strategy where the attacker infects and takes over
    control of zombies.  The attacker could infect multiple zombies, and
    each of those could in turn persuade multiple correspondent nodes to
    send packets to a common victim.  The base of correspondent nodes
    that could be misused would be substantial, because support for
    Mobile IPv6 route optimization is recommended to all IPv6 nodes [14].
    This is why RFC 3775 prevents redirection-based flooding attacks
    through care-of-address test.

    Cryptographically Bound Identifiers (CBIDs, cf. Section 5.9) may be
    used to partly mitigate the risk of flooding, because a correspondent
    node can verify whether the interface identifier of a mobile node's
    (or the attacker's) care-of address is correct.  However, CBIDs do
    not guarantee the correctness of the address prefix.  A malicous node
    could therefore still bomb a certain network even though it may not
    be able to target a particular node within that network.
++++

>>> Section 5.7: I think it might be worthwhile to include a
>>> paragragh describing how the mobile node's credit is measured. I
>>> recently attempted to construct a bandwidth measuring algorithm
>>> and found it not so simple. There are probably very simple ways
>>> to do it, but I think they may not be obvious to the casual
>>> reader.
>>
>> The basic mode for CBA is just packet counting, or rather byte
>> counting.  Paragraph 3 explains this already, I think.
>
> Hmm, so things like bursts and such are not accounted for? It seems
> like a MN wanting to game the system or even an attacker could simply
> bombard the CN with traffic, build up a huge account, then use that
> to mount an attack. I guess I need to read the CBA draft again, it's
> been a while since I read it.

See my response at
http://www1.ietf.org/mail-archive/web/mobopts/current/msg00439.html

>> Perhaps, what you are having in mind is how the CN comes up with a
>> rate limit?  CBA has a loose data-rate limit in that the credit
>> ages over time.  So a MN cannot acquire credit slowly and use it up
>> all at once.  But that's said in the text as well.
>
> Does the CN also use an algorithm where it reduces the credit if it
> thinks that the MN is gaming or it is being bombarded in order to
> build up enough credit to launch an attack? IKE does something like
> this, it reduces the timeout on cookies during IKE_INIT if it thinks
> it is under DoS attack.

Again, see
http://www1.ietf.org/mail-archive/web/mobopts/current/msg00439.html

>> Bandwidth and throughput measurements are not so simple.  Care-of
>> Address Spot Checks can be used to find approximations, which are
>> good enough for the purpose of CBA.  Maybe, this is what was
>> unclear to you?
>
> Yes, perhaps a little more detail would be useful, but I guess
> ultimately people need to read the CBA draft.

I replaced quite a bit of text in section "Credit-Based Authorization".
  It should be much more understandable now.

>>> Section 5.7, para 5.7: I wonder if the Spot Check tokens aren't a
>>>  potential state depletion threat. Since they are essentially per
>>> flow state, an attacker could iterate creating a bunch of flows
>>> until the victim's Spot Check token storage was exhausted.
>>
>> No, the tokens for spot checks can be derived similar to how the CN
>>  creates Home and Care-of Keygen Tokens.  Do you think this should
>> be explained in the text?  I think it may lead too far.
>
> OK, I think people can go back to the original source if they want
> the detail.

I agree.

>>> Section 6.2.4: Can CBA somehow get rid of the need to
>>> re-authorize every 7 minutes? If the MN is building credit, then
>>> perhaps it doesn't need to re-authorize because its ability to
>>> attack is limited by the credit. Of course, the issue of the home
>>> address test would have to be addressed too, but I think it
>>> worthwhile to explore this, since the signaling overhead of RR is
>>> onerous.
>>
>> It can.  We wrote that down in
>
> http://www.watersprings.org/pub/id/draft-arkko-mipv6-binding-lifetime-extension-00.txt
>
>
> Good.

Ok.

>> But why would CGA and CBA have a problem with this?  Both CGA and
>> CBA have a very large applicability; CGA with respect to
>> home-address authentication/authorization and CBA with respect to
>> moving the care-of-address test out of the "critical phase" (which
>> we now have defined ;) ).
>>
>> Foremost, the independence of CGA from infrastructure (you don't
>> need the certification authorities) is very attractive.  And CBA
>> applies to basically every IP-mobility protocol.
>
> Yes, that is exactly my point. These two approaches have the right
> kind of properties for a next-gen solution that should be of wide
> appeal, the others so far don't.

:-)

Alright, that's it.

- Christian

--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

James Kempf wrote:
> Hi Christian,
>
> Thanx for the response. Below, a couple of follow-ups.
>
> jak
>
> --------------------------------------------------------
>
>
>>> Section 4.2, 3rd & 4th para: I've never been convinced that a
>>> mobile node would want to keep optimized routes hot while it was
>>> in dormant mode, and this example doesn't convince me either.
>>> Route optimization helps with RTT latency, and such latency is an
>>> issue primarily in real time traffic. The example given here, a
>>> messaging server (presumably IM), is a store and forward system
>>> that will derive little benefit from keeping routes hot during
>>> optimization. Even for real time traffic, like VoIP, the CN still
>>> has to do SIP signaling to initiate the connection, and while
>>> there is some amount of urgency to the signaling above a store
>>> and forward application, it still is not going to suffer if the
>>> traffic is routed through the home agent. The latency involved in
>>> initiating the IP connection with the dormant mode mobile node
>>> through paging is likely to exceed any benefit from keeping
>>> optimized routes hot.
>>
>> Should we remove the example and say instead that it be worthwhile
>> to save the wireless bandwidth?
>>
>
>
> Yes, I think that should be enough.
>
>
>>> Section 5, para 1: Are the tradeoffs between universal
>>> applicablity v.s. efficiency discussed in this paper anywhere?
>>> This would be the ideal paper to have the discussion.
>>
>> It's mentioned where pre-configuration is discussed, for instance.
>>
>
>
> Might be good to give it a more prominant place, perhaps up front. It
> is a good architectural point, that should not get lost in the
> details of the various techniques.
>
>
>>> Section 5.5, para 2: Later in the paper, you discuss this, but
>>> the statistical uniqueness properties of CGAs suggest that the
>>> care-of test might not be needed since the probability of another
>>> node having exactly the same interface identifier is fairly low.
>>> I think you should state that here. It is the same tradeoff that
>>> optimistic DAD makes. The argument you advance later in the paper
>>> that the attacker can still mount an attack on the subnet is
>>> irrelevent. An attacker can do that without using route
>>> optimization, by creating a zombie and programming it to iterate
>>> through non-existant addresses in the victim subnet.
>>
>> I think there is still an issue with CGAs and RO of which one needs
>> to be aware:
>>
>> An attacker could use any interface identifier in order to bomb a
>> certain network.  The only thing that matters in such a case is the
>>  network prefix.
>>
>> Route optimization does not create the issue with flooding, but it
>> can aggravate it.  You get amplification without programming a
>> zombie and distributing viral software.  And if you choose to
>> program a zombie nonetheless, the zombie can misuse route
>> optimization for you. (In the latter case, the zombie would contact
>> a large set of powerful correspondent nodes, download large files,
>> and redirect those files to the target network.  This is "more
>> efficient" compared to when the zombie alone sends packets.)
>>
>
>
> OK, so it sounds as if RO using CGA w.o. an RR test will provide
additional
> leverage to an attacker, right? Perhaps you could explain this a
little more
> in the draft?
>
>
>
>>> Section 5.7: I think it might be worthwhile to include a
>>> paragragh describing how the mobile node's credit is measured. I
>>> recently attempted to construct a bandwidth measuring algorithm
>>> and found it not so simple. There are probably very simple ways
>>> to do it, but I think they may not be obvious to the casual
>>> reader.
>>
>> The basic mode for CBA is just packet counting, or rather byte
>> counting.  Paragraph 3 explains this already, I think.
>>
>
>
> Hmm, so things like bursts and such are not accounted for? It seems
> like a MN wanting to game the system or even an attacker could simply
> bombard the CN with traffic, build up a huge account, then use that
> to mount an
attack.
> I guess I need to read the CBA draft again, it's been a while since I
> read it.
>
>
>> Perhaps, what you are having in mind is how the CN comes up with a
>> rate limit?  CBA has a loose data-rate limit in that the credit
>> ages over time.  So a MN cannot acquire credit slowly and use it up
>> all at once.  But that's said in the text as well.
>>
>
>
> Does the CN also use an algorithm where it reduces the credit if it
> thinks that the MN is gaming or it is being bombarded in order to
> build up enough credit to launch an attack? IKE does something like
> this, it reduces the timeout on cookies during IKE_INIT if it thinks
> it is under DoS attack.
>
>
>> Bandwidth and throughput measurements are not so simple.  Care-of
>> Address Spot Checks can be used to find approximations, which are
>> good enough for the purpose of CBA.  Maybe, this is what was
>> unclear to you?
>>
>
>
> Yes, perhaps a little more detail would be useful, but I guess
> ultimately people need to read the CBA draft.
>
>
>>> Section 5.7, para 5.7: I wonder if the Spot Check tokens aren't a
>>>  potential state depletion threat. Since they are essentially per
>>> flow state, an attacker could iterate creating a bunch of flows
>>> until the victim's Spot Check token storage was exhausted.
>>
>> No, the tokens for spot checks can be derived similar to how the CN
>>  creates Home and Care-of Keygen Tokens.  Do you think this should
>> be explained in the text?  I think it may lead too far.
>>
>
>
>
> OK, I think people can go back to the original source if they want
> the detail.
>
>
>>> Section 6.2.4: Can CBA somehow get rid of the need to
>>> re-authorize every 7 minutes? If the MN is building credit, then
>>> perhaps it doesn't need to re-authorize because its ability to
>>> attack is limited by the credit. Of course, the issue of the home
>>> address test would have to be addressed too, but I think it
>>> worthwhile to explore this, since the signaling overhead of RR is
>>> onerous.
>>
>> It can.  We wrote that down in
>>
>
>
http://www.watersprings.org/pub/id/draft-arkko-mipv6-binding-lifetime-extension-00.txt
>
>
> Good.
>
>
>> But why would CGA and CBA have a problem with this?  Both CGA and
>> CBA have a very large applicability; CGA with respect to
>> home-address authentication/authorization and CBA with respect to
>> moving the care-of-address test out of the "critical phase" (which
>> we now have defined ;) ).
>>
>> Foremost, the independence of CGA from infrastructure (you don't
>> need the certification authorities) is very attractive.  And CBA
>> applies to basically every IP-mobility protocol.
>>
>
>
> Yes, that is exactly my point. These two approaches have the right
> kind of properties for a next-gen solution that should be of wide
> appeal, the others
> so far don't.
>
> jak

[Mobopts] Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt

Attachment: signature.asc