Subject: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Aug 2006 14:36:51 -0700

Summary: 
---------
Overall, I do believe that MIP6 RO needs to be revised for better
security and optimization. I think using CGAs to generate HoAs is a good
step towards that. From that perspective, this draft is good. I do,
however, think that we don't need any CoA tests (more on that in the
details below). By using CGAs and signed proof to verify HoAs and an
initial HoA test, the CN gets the same assurance about the addresses of
an MN as the HA. That alone is sufficient to generate a binding and
optionally exchange a symmetric key. Hence, I think the "cga" part of
the draft is useful, while the "cba" part is non-essential. 

Having said that, I think it would be best if this document actually
takes a two-step process, going through experimental track first. That
would give us the opportunity to mature the concept and have a solid
proposal for MIP6 RO. I don't think we should target a proposed standard
right away - I think in this case, going to an experimental RFC first is
useful (as we've done before with mobility optimizations such as FMIP
and HMIP). 

Detailed comments  
-----------------

(I've limited these to sections 1 to 3, since that captures the concept)

Major: 
------

1. After some thought, I think we don't need CoA tests (and
consequently, CBA) at all here. In MIP6, CoA test makes sense, since an
attacker has to be present both on the link between the MN and the CN
and on the link between the MN and HA to successfully arrive at the Kbm.
Without the HoTi/HoT or CoTi/CoT, this becomes easier for the attacker,
since presence is required only on one link. However, if the MN's HoA
can be cryptographically verified and the initial HoA test can be done
to (indirectly) prove the existence of a valid registration at the HA,
there should be no need for CoTi/CoT. For e.g., the HA today does not do
a CoA verification - it goes to the same point as in 1 above that if the
MN wants to flood another node by claiming a wrong CoA, it can do that
anyway by other means. 

2. The text under "Initial home address tests" in section 3 is
confusing. I'm not sure I understand the flooding attack as described.
If the goal is to flood any network, as I said in my first point above,
it doesn't need to be done with MIP6. What is more important is ensuring
that an MN that does not have a binding with its HA doesn't end up
creating a binding with a random CN. The fact that the MN has a valid
binding with its HA implies a couple of things - that it has been
authenticated and authorized for MIP6 use and that it is not claiming
another node's HoA. 

Given that, the initial home address test will achieve this - it is just
that the motivation seems to differ in my mind. 

Not-so-major (not-so-minor :))
------------------------------

3. Section 2.2 talks about redirection of an MN's communications to a
third party, thereby flooding the victim (2nd bullet). In my view, this
is not a threat that MIP6 brings. If a malicious node has a goal of
flooding a given node, it doesn't need MIP6 to achieve that. It can send
packets to that IP address and those will do. There isn't a real need to
set up a bogus MIP6 binding to realize that attack. So, I think that
paragraph should be removed. 

4. Also, the point about DoS attacks may stay - but, it is probably
worth mentioning that DoS attacks are achieved by a variety of other
means, some of them, much simpler than engaging in expensive
computations. 

5. Section 3 talks about cryptographically generated home addresses
providing authentication - CGAs provide address ownership validation,
but not really authentication. In order to authenticate a node (i.e., to
verify the node is "who" it claims to be), a verification of its
identity needs to occur - which implies a shared key or a public/private
key pair endorsed by a certificate. I'm assuming this section meant to
really talk about HoA ownership validation? 

Vidya

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 8 Aug 2006 01:18:12 +0300 (EEST)

Just want to ask you if you have read the charter of the mipshop WG?
Or maybe you're planning to write another one soon?!

Wassim H.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Aug 2006 15:49:35 -0700

Wassim,
I have and I'm expressing my opinion along with detailed technical
comments. If you have specific points to make, please do so. 

Vidya 

> -----Original Message-----
> From: Wassim Haddad [mailto:[email-masked]] 
> Sent: Monday, August 07, 2006 3:18 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> Subject: Re: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04
> 
> > security and optimization. I think using CGAs to generate HoAs is a 
> > good step towards that. From that perspective, this draft 
> is good. I 
> > do, however, think that we don't need any CoA tests (more 
> on that in 
> > the details below). By using CGAs and signed proof to 
> verify HoAs and 
> > an initial HoA test, the CN gets the same assurance about the 
> > addresses of an MN as the HA. That alone is sufficient to 
> generate a 
> > binding and optionally exchange a symmetric key. Hence, I think the 
> > "cga" part of the draft is useful, while the "cba" part is 
> non-essential.
> >
> > proposal for MIP6 RO. I don't think we should target a proposed 
> > standard right away - I think in this case, going to an 
> experimental 
> > RFC first is useful (as we've done before with mobility 
> optimizations 
> > such as FMIP and HMIP).
> >
> > Detailed comments
> > -----------------
> >
> > consequently, CBA) at all here. In MIP6, CoA test makes 
> sense, since 
> > an attacker has to be present both on the link between the 
> MN and the 
> > CN and on the link between the MN and HA to successfully 
> arrive at the Kbm.
> > Without the HoTi/HoT or CoTi/CoT, this becomes easier for the 
> > attacker, since presence is required only on one link. 
> However, if the 
> > MN's HoA can be cryptographically verified and the initial HoA test 
> > can be done to (indirectly) prove the existence of a valid 
> > registration at the HA, there should be no need for CoTi/CoT. For 
> > e.g., the HA today does not do a CoA verification - it goes to the 
> > same point as in 1 above that if the MN wants to flood 
> another node by 
> > claiming a wrong CoA, it can do that anyway by other means.
> >
> > If the goal is to flood any network, as I said in my first point 
> > above, it doesn't need to be done with MIP6. What is more 
> important is 
> > ensuring that an MN that does not have a binding with its 
> HA doesn't 
> > end up creating a binding with a random CN. The fact that 
> the MN has a 
> > valid binding with its HA implies a couple of things - that it has 
> > been authenticated and authorized for MIP6 use and that it is not 
> > claiming another node's HoA.
> >
> > Given that, the initial home address test will achieve this - it is 
> > just that the motivation seems to differ in my mind.
> >
> > third party, thereby flooding the victim (2nd bullet). In my view, 
> > this is not a threat that MIP6 brings. If a malicious node 
> has a goal 
> > of flooding a given node, it doesn't need MIP6 to achieve 
> that. It can 
> > send packets to that IP address and those will do. There 
> isn't a real 
> > need to set up a bogus MIP6 binding to realize that attack. So, I 
> > think that paragraph should be removed.
> >
> > but not really authentication. In order to authenticate a 
> node (i.e., 
> > to verify the node is "who" it claims to be), a verification of its 
> > identity needs to occur - which implies a shared key or a 
> > public/private key pair endorsed by a certificate. I'm 
> assuming this 
> > section meant to really talk about HoA ownership validation?
> >
> >
> > Vidya
> >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 7 Aug 2006 16:04:51 -0700

A minor correction inline below.  

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Monday, August 07, 2006 2:37 PM
> To: [email-masked]
> Subject: [Mipshop] Review of draft-arkko-mipshop-cga-cba-04
> 
> 
> Summary: 
> ---------
> Overall, I do believe that MIP6 RO needs to be revised for 
> better security and optimization. I think using CGAs to 
> generate HoAs is a good step towards that. From that 
> perspective, this draft is good. I do, however, think that we 
> don't need any CoA tests (more on that in the details below). 
> By using CGAs and signed proof to verify HoAs and an initial 
> HoA test, the CN gets the same assurance about the addresses 
> of an MN as the HA. That alone is sufficient to generate a 
> binding and optionally exchange a symmetric key. Hence, I 
> think the "cga" part of the draft is useful, while the "cba" 
> part is non-essential. 
> 
> Having said that, I think it would be best if this document 
> actually takes a two-step process, going through experimental 
> track first. That would give us the opportunity to mature the 
> concept and have a solid proposal for MIP6 RO. I don't think 
> we should target a proposed standard right away - I think in 
> this case, going to an experimental RFC first is useful (as 
> we've done before with mobility optimizations such as FMIP and HMIP). 
> 
> Detailed comments
> -----------------
> 
> sense, since an attacker has to be present both on the link 
> between the MN and the CN and on the link between the MN and 
> HA to successfully arrive at the Kbm.
> However, if the MN's HoA can be cryptographically verified 
> and the initial HoA test can be done to (indirectly) prove 
> the existence of a valid registration at the HA, there should 
> be no need for CoTi/CoT. For e.g., the HA today does not do a 
> CoA verification - it goes to the same point as in 1 above 

I meant the same point as in 3 below (I did some re-numbering and forgot
to correct this). 

Thanks,
Vidya

> that if the MN wants to flood another node by claiming a 
> wrong CoA, it can do that anyway by other means. 
> 
> 2. The text under "Initial home address tests" in section 3 
> is confusing. I'm not sure I understand the flooding attack 
> as described.
> If the goal is to flood any network, as I said in my first 
> point above, it doesn't need to be done with MIP6. What is 
> more important is ensuring that an MN that does not have a 
> binding with its HA doesn't end up creating a binding with a 
> random CN. The fact that the MN has a valid binding with its 
> HA implies a couple of things - that it has been 
> authenticated and authorized for MIP6 use and that it is not 
> Given that, the initial home address test will achieve this - 
> it is just that the motivation seems to differ in my mind. 
> 
> 3. Section 2.2 talks about redirection of an MN's 
> communications to a third party, thereby flooding the victim 
> (2nd bullet). In my view, this is not a threat that MIP6 
> brings. If a malicious node has a goal of flooding a given 
> node, it doesn't need MIP6 to achieve that. It can send 
> packets to that IP address and those will do. There isn't a 
> real need to set up a bogus MIP6 binding to realize that 
> attack. So, I think that paragraph should be removed. 
> 
> 4. Also, the point about DoS attacks may stay - but, it is 
> probably worth mentioning that DoS attacks are achieved by a 
> variety of other means, some of them, much simpler than 
> engaging in expensive computations. 
> 
> 5. Section 3 talks about cryptographically generated home 
> addresses providing authentication - CGAs provide address 
> ownership validation, but not really authentication. In order 
> to authenticate a node (i.e., to verify the node is "who" it 
> claims to be), a verification of its identity needs to occur 
> - which implies a shared key or a public/private key pair 
> endorsed by a certificate. I'm assuming this section meant to

---

From: Christian Vogt <[email-masked]>
Date: Tue, 08 Aug 2006 18:36:47 +0200

Hi Vidya,

thanks for reviewing this document!  I'll respond in-line.

> Summary: --------- 
> Overall, I do believe that MIP6 RO needs to be
> revised for better security and optimization. I think using CGAs to
> generate HoAs is a good step towards that. From that perspective,
> this draft is good. I do, however, think that we don't need any CoA
> tests (more on that in the details below). By using CGAs and signed
> proof to verify HoAs and an initial HoA test, the CN gets the same
> assurance about the addresses of an MN as the HA. That alone is
> sufficient to generate a binding and optionally exchange a symmetric
> key. Hence, I think the "cga" part of the draft is useful, while the
> "cba" part is non-essential.

You are touching two points here:  (i) whether or not MIPv6 could be
useful for flooding, and (ii) whether or not a CoA test is necessary in
the presence of a home address ownership proof and a proof of home agent
registration.  Let me address these points separately.

(i)  From an attacker's perspective, the advantage of MIPv6-based
flooding (or redirection-based flooding) over "classic" flooding
techniques (ignore DDos for the moment) is that it can provide much
higher amplification:  The attacker won't need to send as much packets
to the correspondent node as the correspondent node will send to the
victim.  Amplification makes the big difference between classic flooding
and redirection-based flooding.

By "classic" flooding, I here refer to direct flooding attacks (where
the attacker itself simply sends packets to the victim), or reflection
attacks like TCP-SYN or Smurf attacks.  Direct flooding attacks
obviously don't provide any amplification.  TCP-SYN and Smurf attacks
usually don't amply much either, provided that network administrators
follow CERT advisories.

Of course, in addition to these classic flooding strategies, there are
DDoS attacks, which /do/ provide amplification.  But DDoS attacks are
different from classic or redirection-based flooding attacks in the
sense that they typically exploit vulnerabilities in operating systems
rather than vulnerabilities in Internet protocols.  OS developers are
doing their part to avoid amplified flooding in that they patch flaws in
their software.  We in IETF should contribute our part to avoid
vulnerabilities in the protocols we develop.

As a side note, DDoS and redirection-based flooding could also be
combined:  Why not command zombies to redirect a CN's packets to the
victim instead of having the zombies send the flooding packets
themselves?  Many zombies are probably private home computers, which may
have limited upstream connectivity.  So they may not be able to generate
that many flooding packets, but they can certainly trick
better-provisioned CNs into sending packets to a victim.

The issue of redirection has long been taken care of in the non-mobile
Internet, where transport protocols perform an initial reachability
verification upon connection establishment.  E.g., a TCP responder sends
an unguessable sequence number to the TCP initiator.  Without knowing
the sequence number, the initiator won't receive any data.  DCCP and
SCTP do similar tricks in order to verify an initiator's IP address
initially.  Now, mobility protocols (and also multi-homing protocols)
can be used to change the IP address a posteriori, which means that the
reachability verification must be done again.  This is the purpose of
the CoA test.

And this brings me to the second point...

(ii)  ...which is whether a home address ownership proof, combined with
a proof of home agent registration, would allow a CN to omit
reachability verification for a new CoA.

First of all, a home address ownership proof does not increase the
trustworthiness of a MN from the perspective of a CN.  The home address
does not even have to be a permanent one.  An attacker could just
configure a CBA-based HoA with a network prefix from its current link,
use the same or a different IP address from that prefix as its CoA, and
start registering with the CN.  There does not even have to be a HA.
This issue is the very same in RFC 3775 as in the proposed CGA-CBA
protocol.  While the CGA-based home address ownership verification makes
impersonation attacks much harder (which is why we use it), it does not
change the practicability or likelihood of redirection-based flooding.

For the same reason, the CN cannot trust that there really is a HA with
which the MN has registered.  The HA may be cooperating with the
attacker, it there may be no HA at all.  After all, the CN never sees an
authenticated message from the HA.  The home registration is really
irrelevant for the correspondent registration from a security
perspective (except that you could otherwise use the IPsec-protected
tunnel between the HA and the MN).

Second, you mention that in standard MIPv6, an attacker would have to be
on two paths---between the HA and the CN as well as between the MN and
the CN---in order to break the return routability procedure.  This is
actually not the case; sitting on the HA-CN path is sufficient.  The
attacker would use the victim's HoA, but it's own CoA.  It can thus
exchange both HoTI/HoT and CoTI/CoT with the CN on behalf of the victim.
 Note, however, that this would be an impersonation attack.  Flooding
can be combined with impersonation, but also a correctly authenticated
(possibly compromised) MN may wage a flooding attack.

It is true that RFC 3775 does not include a CoA test for home
registrations.  But the motivation for this was not that the HA can
securely verify the MN's home address ownership, or that the home
registration is IPsec-protected.  The motivation rather was that, first,
the HA can trust the MNs that they use the right CoA and, second, that
there is an administrative relationship between the HA and the MN so
that a MN can always be tracked down if it still behaves maliciously
(e.g., when the MN was compromised).

The same rationale was used in Charlie's RFC 4449 (Securing Mobile IPv6
Route Optimization Using a Static Shared Key):  It assumes that, first,
MNs and CNs are under a common administration and, second, that they
trust each other.  There was an extensive debate in the MIP6 working
group on whether this assumption would limit the applicability of the
technique too much.  But in the end, the assumption was written down as
such.  (It's in section 2 of RFC 4449 in case you want to take a look.)

Given that the envisioned CGA-CBA protocol should not be limited to MNs
and CN with a-priori relationships, we need to avoid the assumptions
made in RFC 4449.  This in turn means that we have to do the CoA test.
And we want to optimize them.

> takes a two-step process, going through experimental track first.
> That would give us the opportunity to mature the concept and have a
> solid proposal for MIP6 RO. I don't think we should target a proposed
> standard right away - I think in this case, going to an experimental
> RFC first is useful (as we've done before with mobility optimizations
> such as FMIP and HMIP).

Vidya, the introduction of a new OSI layer for a host identifier as well
as the architecture required for localized mobility optimizations are
certainly more tricky than a proof of IP address ownership or some byte
counting during concurrent reachability verification.

Also, AFAICT, one of the reasons for making FMIP and HMIP experimental
in the first round was lack of a sufficient security mechanism in both
cases.  Mipshop is now taking care of this.

> Detailed comments -----------------
> 
> Major: ------
> consequently, CBA) at all here. In MIP6, CoA test makes sense, since
> an attacker has to be present both on the link between the MN and the
> CN and on the link between the MN and HA to successfully arrive at
> the Kbm. Without the HoTi/HoT or CoTi/CoT, this becomes easier for
> the attacker, since presence is required only on one link. However,
> if the MN's HoA can be cryptographically verified and the initial HoA
> test can be done to (indirectly) prove the existence of a valid
> same point as in 1 above that if the MN wants to flood another node
> by claiming a wrong CoA, it can do that anyway by other means.

Please see my comments above wrt. both, why it is sufficient for an
attacker to only be on the HA-CN path, as well as why we still require
the CoA test.

> confusing. I'm not sure I understand the flooding attack as
> described. If the goal is to flood any network, as I said in my first
> point above, it doesn't need to be done with MIP6. What is more
> important is ensuring that an MN that does not have a binding with
> its HA doesn't end up creating a binding with a random CN. The fact
> that the MN has a valid binding with its HA implies a couple of
> things - that it has been authenticated and authorized for MIP6 use
> and that it is not claiming another node's HoA.

Again, see my comments above wrt. to the value of a home registration
from the CN's perspective.

However, I will certainly take a look at section 3 and clarify the text.

> Not-so-major (not-so-minor :)) ------------------------------
> 
> this is not a threat that MIP6 brings. If a malicious node has a goal
> of flooding a given node, it doesn't need MIP6 to achieve that. It
> can send packets to that IP address and those will do. There isn't a
> real need to set up a bogus MIP6 binding to realize that attack. So,
> I think that paragraph should be removed.
> 

You are right; I will add this.

>  but not really authentication. In order to authenticate a node
> (i.e., to verify the node is "who" it claims to be), a verification
> of its identity needs to occur - which implies a shared key or a
> public/private key pair endorsed by a certificate. I'm assuming this

Absolutely right.  Need to clarify that.

Thanks again!

Best,
- Christian

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

"Everything should be made as simple as possible, but not simpler."
(Albert Einstein)

Narayanan, Vidya wrote:
> Summary: --------- Overall, I do believe that MIP6 RO needs to be
> revised for better security and optimization. I think using CGAs to
> generate HoAs is a good step towards that. From that perspective,
> this draft is good. I do, however, think that we don't need any CoA
> tests (more on that in the details below). By using CGAs and signed
> proof to verify HoAs and an initial HoA test, the CN gets the same
> assurance about the addresses of an MN as the HA. That alone is
> sufficient to generate a binding and optionally exchange a symmetric
> key. Hence, I think the "cga" part of the draft is useful, while the
> "cba" part is non-essential.
> 
> takes a two-step process, going through experimental track first.
> That would give us the opportunity to mature the concept and have a
> solid proposal for MIP6 RO. I don't think we should target a proposed
> standard right away - I think in this case, going to an experimental
> RFC first is useful (as we've done before with mobility optimizations
> such as FMIP and HMIP).
> 
> Detailed comments -----------------
> 
> Major: ------
> consequently, CBA) at all here. In MIP6, CoA test makes sense, since
> an attacker has to be present both on the link between the MN and the
> CN and on the link between the MN and HA to successfully arrive at
> the Kbm. Without the HoTi/HoT or CoTi/CoT, this becomes easier for
> the attacker, since presence is required only on one link. However,
> if the MN's HoA can be cryptographically verified and the initial HoA
> test can be done to (indirectly) prove the existence of a valid
> same point as in 1 above that if the MN wants to flood another node
> by claiming a wrong CoA, it can do that anyway by other means.
> 
> confusing. I'm not sure I understand the flooding attack as
> described. If the goal is to flood any network, as I said in my first
> point above, it doesn't need to be done with MIP6. What is more
> important is ensuring that an MN that does not have a binding with
> its HA doesn't end up creating a binding with a random CN. The fact
> that the MN has a valid binding with its HA implies a couple of
> things - that it has been authenticated and authorized for MIP6 use
> and that it is not claiming another node's HoA.
> 
> Not-so-major (not-so-minor :)) ------------------------------
> 
> this is not a threat that MIP6 brings. If a malicious node has a goal
> of flooding a given node, it doesn't need MIP6 to achieve that. It
> can send packets to that IP address and those will do. There isn't a
> real need to set up a bogus MIP6 binding to realize that attack. So,
> I think that paragraph should be removed.
> 
>  but not really authentication. In order to authenticate a node
> (i.e., to verify the node is "who" it claims to be), a verification
> of its identity needs to occur - which implies a shared key or a
> public/private key pair endorsed by a certificate. I'm assuming this

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 14 Aug 2006 11:16:11 -0700

Hi Christian,
Thanks for taking the time to respond. It is extremely refreshing to be
having a technical discussion! Also, apologies for the delayed response
- last week turned out to be very busy. 

I want to separate the topics out, since these are long discussions.
I'll start separate threads on a couple of other related topics after
this. 

Summarizing the means by which flooding attacks can be realized: 

1. Directly flooding the victim by sending traffic to the victim - as
you pointed out, this requires reasonable amount of effort on the
attacker's part. 

2. Subscribing for bogus sessions using a victim's IP address (TCP has
some behavior that can help here, for e.g., slowing down if proper acks
aren't received, but it is possible to subscribe to UDP/RTP sessions).
This would allow the attacker to amplify the attack without too much
direct resource involvement. 

3. Using MIP6 home subscription to redirect traffic to the victim. Of
course, the risk here is that of authenticated nodes registering the
victim's IP address as its CoA. 

4. Using MIP6 RO to redirect traffic to the victim. If there is a HoA
test, here too, the risk is that of authenticated nodes registering the
victim's IP address as its CoA. The HoA test cannot pass unless there is
a valid binding for that node at the HA. When the HoA is created with
CGAs, this situation has full equivalence with the home subscription.
Note that I'm still not saying the MN-HA authenticated state has any
meaning to the CN. 

If I understand correctly, you are saying that MIP6 can be used to
amplify flooding attacks. Even though I think in practice, 2 above can
be used to amplify flooding attacks, if that is the intention, I can buy
the argument that if say, 2 is solved by other means, you will still be
left with the possibility of amplification via 3 and 4. 

However, the point I struggle with is this - as I've said above, I think
there is equivalence in the attack that is possible with 3 and 4,
assuming that the HoA is based on CGAs and a HoA test is done. So, if we
say RR for CoA is needed, it is equally needed for 3 and 4. I don't see
why it is needed for 4 alone in this case. 

Thoughts? 

Vidya

> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Tuesday, August 08, 2006 9:37 AM
> To: Narayanan, Vidya
> Cc: [email-masked]; Jari Arkko; Wassim Haddad
> You are touching two points here:  (i) whether or not MIPv6 
> could be useful for flooding, and (ii) whether or not a CoA 
> test is necessary in the presence of a home address ownership 
> proof and a proof of home agent registration.  Let me address 
> these points separately.
> 
> (i)  From an attacker's perspective, the advantage of 
> MIPv6-based flooding (or redirection-based flooding) over 
> "classic" flooding techniques (ignore DDos for the moment) is 
> that it can provide much higher amplification:  The attacker 
> won't need to send as much packets to the correspondent node 
> as the correspondent node will send to the victim.  
> Amplification makes the big difference between classic 
> flooding and redirection-based flooding.
> 
> By "classic" flooding, I here refer to direct flooding 
> attacks (where the attacker itself simply sends packets to 
> the victim), or reflection attacks like TCP-SYN or Smurf 
> attacks.  Direct flooding attacks obviously don't provide any 
> amplification.  TCP-SYN and Smurf attacks usually don't amply 
> much either, provided that network administrators follow CERT 
> advisories.
> 
> Of course, in addition to these classic flooding strategies, 
> there are DDoS attacks, which /do/ provide amplification.  
> But DDoS attacks are different from classic or 
> redirection-based flooding attacks in the sense that they 
> typically exploit vulnerabilities in operating systems rather 
> than vulnerabilities in Internet protocols.  OS developers 
> are doing their part to avoid amplified flooding in that they 
> patch flaws in their software.  We in IETF should contribute 
> our part to avoid vulnerabilities in the protocols we develop.
> 
> combined:  Why not command zombies to redirect a CN's packets 
> to the victim instead of having the zombies send the flooding 
> packets themselves?  Many zombies are probably private home 
> computers, which may have limited upstream connectivity.  So 
> they may not be able to generate that many flooding packets, 
> but they can certainly trick better-provisioned CNs into 
> sending packets to a victim.
> 
> The issue of redirection has long been taken care of in the 
> non-mobile Internet, where transport protocols perform an 
> initial reachability verification upon connection 
> establishment.  E.g., a TCP responder sends an unguessable 
> sequence number to the TCP initiator.  Without knowing the 
> sequence number, the initiator won't receive any data.  DCCP 
> and SCTP do similar tricks in order to verify an initiator's 
> IP address initially.  Now, mobility protocols (and also 
> multi-homing protocols) can be used to change the IP address 
> a posteriori, which means that the reachability verification 
> must be done again.  This is the purpose of the CoA test.
> 
> (ii)  ...which is whether a home address ownership proof, 
> combined with a proof of home agent registration, would allow 
> a CN to omit reachability verification for a new CoA.
> 
> First of all, a home address ownership proof does not 
> increase the trustworthiness of a MN from the perspective of 
> a CN.  The home address does not even have to be a permanent 
> one.  An attacker could just configure a CBA-based HoA with a 
> network prefix from its current link, use the same or a 
> different IP address from that prefix as its CoA, and start 
> registering with the CN.  There does not even have to be a HA.
> This issue is the very same in RFC 3775 as in the proposed 
> CGA-CBA protocol.  While the CGA-based home address ownership 
> verification makes impersonation attacks much harder (which 
> is why we use it), it does not change the practicability or 
> likelihood of redirection-based flooding.
> 
> For the same reason, the CN cannot trust that there really is 
> a HA with which the MN has registered.  The HA may be 
> cooperating with the attacker, it there may be no HA at all.  
> After all, the CN never sees an authenticated message from 
> the HA.  The home registration is really irrelevant for the 
> correspondent registration from a security perspective 
> (except that you could otherwise use the IPsec-protected 
> Second, you mention that in standard MIPv6, an attacker would 
> have to be on two paths---between the HA and the CN as well 
> as between the MN and the CN---in order to break the return 
> routability procedure.  This is actually not the case; 
> sitting on the HA-CN path is sufficient.  The attacker would 
> use the victim's HoA, but it's own CoA.  It can thus exchange 
> both HoTI/HoT and CoTI/CoT with the CN on behalf of the victim.
>  Note, however, that this would be an impersonation attack.  
> Flooding can be combined with impersonation, but also a 
> correctly authenticated (possibly compromised) MN may wage a 
> flooding attack.
> 
> registrations.  But the motivation for this was not that the 
> HA can securely verify the MN's home address ownership, or 
> that the home registration is IPsec-protected.  The 
> motivation rather was that, first, the HA can trust the MNs 
> that they use the right CoA and, second, that there is an 
> administrative relationship between the HA and the MN so that 
> a MN can always be tracked down if it still behaves 
> maliciously (e.g., when the MN was compromised).
> 
> The same rationale was used in Charlie's RFC 4449 (Securing 
> Mobile IPv6 Route Optimization Using a Static Shared Key):  
> It assumes that, first, MNs and CNs are under a common 
> administration and, second, that they trust each other.  
> There was an extensive debate in the MIP6 working group on 
> whether this assumption would limit the applicability of the 
> technique too much.  But in the end, the assumption was 
> written down as such.  (It's in section 2 of RFC 4449 in case 
> you want to take a look.)
> 
> Given that the envisioned CGA-CBA protocol should not be 
> limited to MNs and CN with a-priori relationships, we need to 
> avoid the assumptions made in RFC 4449.  This in turn means 
> that we have to do the CoA test.
> actually 
> Vidya, the introduction of a new OSI layer for a host 
> identifier as well as the architecture required for localized 
> mobility optimizations are certainly more tricky than a proof 
> of IP address ownership or some byte counting during 
> concurrent reachability verification.
> 
> Also, AFAICT, one of the reasons for making FMIP and HMIP 
> experimental in the first round was lack of a sufficient 
> security mechanism in both cases.  Mipshop is now taking care of this.
> 
> arrive at the 
> > Kbm. Without the HoTi/HoT or CoTi/CoT, this becomes easier for the 
> Please see my comments above wrt. both, why it is sufficient 
> for an attacker to only be on the HA-CN path, as well as why 
> we still require the CoA test.
> 
> described. 
> Again, see my comments above wrt. to the value of a home 
> registration from the CN's perspective.
> 
> communications to a  
> Christian Vogt, Institute of Telematics, Universitaet 
> Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/
> 
> perspective, this 
> > draft is good. I do, however, think that we don't need any 
> CoA tests 
> > (more on that in the details below). By using CGAs and 
> signed proof to 
> > verify HoAs and an initial HoA test, the CN gets the same assurance 
> > about the addresses of an MN as the HA. That alone is sufficient to 
> > generate a binding and optionally exchange a symmetric key. 
> Hence, I 
> > think the "cga" part of the draft is useful, while the 
> "cba" part is 
> > non-essential.
> > 
> actually 
> arrive at the 
> > Kbm. Without the HoTi/HoT or CoTi/CoT, this becomes easier for the 
> described. 
> communications to a

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 14 Aug 2006 11:21:41 -0700

Christian, all,
One question regarding CGA-based HoAs - don't we need to specify how
CGA-based HoAs impact home registrations? For instance, the preferred
HoA bootstrapping mechanism today is using IKEv2. I'd imagine that we
will need to specify how a CGA-based HoA is generated after MPD and how
that binding is registered with the HA (i.e., does it need to be signed?
Does the HA also need to know if the HoA has been generated using
CGAs?). 

I would imagine needing this to support CGA-based HoA for RO - is that a
valid assumption? If not, could you please explain why this is not
needed for home registrations? 

Thanks,
Vidya

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Aug 2006 23:07:30 +0300

Viday,

Thanks a lot of your review and starting an interesting

>you pointed out, this requires reasonable amount of effort on the
Right.

>direct resource involvement. 
Yes -- but I believe for TCP this is hard, because it would imply being
able to guess the sequence numbers. Otherwise the session won't even
start. There are ways to guess the sequence numbers, but at least some of
those ways involve additional cost for the attacker.

>victim's IP address as its CoA. 
Right. TCP is not a barrier here.

>Note that I'm still not saying the MN-HA authenticated state has any
That is the crux of the matter. Whatever arrangement exists between the MN
and its HA is invisible to the CN (under the assumption of talking to a
random
Internet host). What the CN sees with a home test is that the MN appears
to be in control of receiving traffic at the home address. This is
sufficient
for agreeing to route traffic relating to that address differently, but it
does not say anything about the existence of the node at the care of
address.

Of course, if there's a problem, the CN can go and complain to the home
network's admin. The admin may be able to find out the offending node and
turn it off. But the victim network admin needs to talk to both the CN
network
and then indirectly the home network to get this started; during the design
of the original RR mechanisms it was felt that its better to provide a
mechanism
that helps prevent these situations -- even if the network admin and
authorities
could sort out the situation later.

>left with the possibility of amplification via 3 and 4.
I believe 2 is harder to achieve with TCP from the attacker's point of view
than 3 (and 4 if we didn't have RR).

I am sure there are non-TCP attacks of class 2 that are serious. My belief
is that we should work to reduce these amplification vulnerabilities
in the entire stack.

>why it is needed for 4 alone in this case. 
Let me first state that if I could redesign RFC 3775 today, I would probably
NOT include an administrative security association relationship for the
MN - HA. This would have made deployment much easier (e.g. DHCP
assigned home agents without any of the bootstrapping complexity).
And it would have gotten us rid of problem #3.

We have occasionally talked about this change, though not very
seriously -- and I would not hold it as a precondition for doing RO
enhancements. In any case, in the current deployment model of
Mobile IPv6 there is an administrative relationship which can be
used to shut down misbehaving nodes or even send the authorities
to catch the guilty. I still like to have a stronger flooding amplification
protection for the MN - CN relationship -- particularly if it does not
have a cost in communications latency.

--Jari

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 14 Aug 2006 13:18:20 -0700

> Jari Arkko wrote: 
> Good question! I do not recall if this has been analyzed 
> during the design of cga-cba draft. But taking a look at 
> draft-ietf-mip6-ikev2-ipsec, it does allow the mobile node to 
> suggest what address to use. I'm not sure the draft says 
> anything about discovering the prefix first before suggesting 
> an address (which would be needed for CGAs), but this seems 
> in general possible in IKEv2. Vijay, are you listening?
> 

That is one part of the open question. The other part is to analyze
whether this has any implication for the home bindings itself - i.e., if
the HA knows that this is a CGA-based HoA and if it needs to be asserted
via a signature, etc. For the moment, I think I can look at it both ways
:) But, this needs to be thought through further. 

This would have significant implications to the cga-cba work, in the
sense that if we determine that home bindings will need to change, that
needs to be first standardized and then CGA-based RO can be built on top
of that. 

Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 14 Aug 2006 14:38:55 -0700

Hi Jari,

<snip>

> >  
> >
> Yes -- but I believe for TCP this is hard, because it would 
> imply being able to guess the sequence numbers. Otherwise the 
> session won't even start. There are ways to guess the 
> sequence numbers, but at least some of those ways involve 
> additional cost for the attacker.
> 

I'd somewhat buy that :) I think spoofing the acks can be done, but it
does involve some cost. 

<snip>

> >
> That is the crux of the matter. Whatever arrangement exists 
> between the MN and its HA is invisible to the CN (under the 
> assumption of talking to a random Internet host). What the CN 
> sees with a home test is that the MN appears to be in control 
> of receiving traffic at the home address. This is sufficient 
> for agreeing to route traffic relating to that address 
> differently, but it does not say anything about the existence 
> of the node at the care of address.
> 
> Of course, if there's a problem, the CN can go and complain 
> to the home network's admin. The admin may be able to find 
> out the offending node and turn it off. But the victim 
> network admin needs to talk to both the CN network and then 
> indirectly the home network to get this started; during the 
> design of the original RR mechanisms it was felt that its 
> better to provide a mechanism that helps prevent these 
> situations -- even if the network admin and authorities could 
> sort out the situation later.
> 

I don't quite agree that the above situation is any different for home
registration vs. RO. Here's why - in both cases, let's assume that the
victim is some random node in the internet that does not have any
relationship with the home domain of the MN (attacker). In both cases,
the packets arriving at the victim has the CN IP address, the HoA and
the CoA (the victim's IP address, in this case) available to it. The
victim additionally has the HA IP address available to it in the HA
routed case. However, considering that the victim is a random node with
no relationship to the home domain, it needs to deduce the home domain
from the IP addresses and then complain. It can do this in both cases.
In both cases, deniability is also equally possible, since the home
domain could claim that the attacker is the CN in both cases. 

Given that a "complaint" has to take the form of an email or a phone
call or something tangible, this is equally feasible (or not, actually,
in my mind!) in both cases. The added availability of the HA IP address
really doesn't mean anything as far as I can see. 

<snip>

> >  
> >
> Let me first state that if I could redesign RFC 3775 today, I 
> would probably NOT include an administrative security 
> association relationship for the MN - HA. This would have 
> made deployment much easier (e.g. DHCP assigned home agents 
> without any of the bootstrapping complexity).
> We have occasionally talked about this change, though not 
> very seriously -- and I would not hold it as a precondition 
> for doing RO enhancements. In any case, in the current 
> deployment model of Mobile IPv6 there is an administrative 
> relationship which can be used to shut down misbehaving nodes 
> or even send the authorities to catch the guilty. I still 
> like to have a stronger flooding amplification protection for 
> the MN - CN relationship -- particularly if it does not have 
> a cost in communications latency.
> 

The whole admin thing being some level of protection here is quite
bizzarre to me :) - but, even if I made the leap to embrace that, I
still feel there is equivalence as I've described above. What am I
missing? 

Vidya

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Aug 2006 23:12:36 +0300

Good question! I do not recall if this has been analyzed
during the design of cga-cba draft. But taking a look at
draft-ietf-mip6-ikev2-ipsec, it does allow the mobile node
to suggest what address to use. I'm not sure the draft
says anything about discovering the prefix first before
suggesting an address (which would be needed for CGAs),
but this seems in general possible in IKEv2. Vijay, are
you listening?

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Aug 2006 16:46:23 -0700

> And it would have gotten us rid of problem #3.

we could add a return routability check for the home agent
to check if the mobile node is at the CoA it is claiming in
the BU. but AFAIK, it has not been seen as an issue so far.

regarding the "administrative security association
relationship", things are no longer so rigid (RFC 3775 ties
an SA to the home address) with the bootstrapping specs. the
mobile node can be assigned any random home agent as long as
there is a way to authenticate each other.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 14 Aug 2006 22:17:45 -0700

> Vijay Devarapalli wrote: 

> > Let me first state that if I could redesign RFC 3775 today, I would 
> > probably NOT include an administrative security association 
> > relationship for the MN - HA. This would have made deployment much 
> > easier (e.g. DHCP assigned home agents without any of the 
> bootstrapping complexity).
> we could add a return routability check for the home agent to 
> check if the mobile node is at the CoA it is claiming in the 
> BU. but AFAIK, it has not been seen as an issue so far.
> 

I don't think adding a RR test for the CoA for home registration is a
good thing - this has to be repeated every time the CoA changes. Also,
I'm not saying this is needed. However, I am saying that there is
equivalence in home and CN registrations when CGA is used to create the
HoA and hence the RR test for CoA is NOT needed for the CN registrations
:) 

If this is seen as a huge problem, then it must be addressed for home
and CN registerations alike. I think that, for now, we can note the
issue and stop at that. 

> there is a way to authenticate each other.

Agreed. 

Vidya

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Aug 2006 09:50:34 +0200

Hi Vidya, hi Jari.

>> 4. Using MIP6 RO to redirect traffic to the victim. If there is a 
>> HoA test, here too, the risk is that of authenticated nodes 
>> registering the victim's IP address as its CoA. The HoA test cannot
>>  pass unless there is a valid binding for that node at the HA. When
>>  the HoA is created with CGAs, this situation has full equivalence 
>> with the home subscription. Note that I'm still not saying the 
>> MN-HA authenticated state has any meaning to the CN.
>> 
> That is the crux of the matter. Whatever arrangement exists between 
> the MN and its HA is invisible to the CN (under the assumption of 
> talking to a random Internet host). What the CN sees with a home test
>  is that the MN appears to be in control of receiving traffic at the 
> home address. This is sufficient for agreeing to route traffic 
> relating to that address differently, but it does not say anything 
> about the existence of the node at the care of address.
> 
> Of course, if there's a problem, the CN can go and complain to the 
> home network's admin. The admin may be able to find out the offending
>  node and turn it off. But the victim network admin needs to talk to 
> both the CN network and then indirectly the home network to get this 
> started; during the design of the original RR mechanisms it was felt 
> that its better to provide a mechanism that helps prevent these 
> situations -- even if the network admin and authorities could sort 
> out the situation later.

Yes, this is one point:  Proactivity is better than reactivity.

Another thing is that there may actually be no home agent and home
domain admin which a victim could contact.  (I mentioned this in the
previous email, but I guess it was lost in the noise.)  E.g., an
attacker may attach to a public WLAN, acquire a (possibly temporary) IP
address, and use this IP address as a HoA in combination with a false
CoA.  The attacker itself would then play the HA part during the HoA test.

Of course, the HoA test would in this case guarantee the attacker's
reachability of the alleged "HoA", and hence a victim could
theoretically track the attacker down by contacting the public WLAN
provider.  But there is no clear and, more importantly, fast procedure
that the victim could follow.

Also note that the business relationship between the attacker and the
public WLAN provider may only be of temporary nature (e.g., an hourly
subscription).

Ciao,
- Christian

Jari Arkko wrote:
> Viday,
> 
> Thanks a lot of your review and starting an interesting technical
> discussion! Some further comments inline:
> 
>> I want to separate the topics out, since these are long
>> discussions. I'll start separate threads on a couple of other
>> related topics after this.
>> 
>> 1. Directly flooding the victim by sending traffic to the victim -
>> as you pointed out, this requires reasonable amount of effort on
>> the attacker's part.
>> 
>> 
> Right.
> 
>> 2. Subscribing for bogus sessions using a victim's IP address (TCP
>> has some behavior that can help here, for e.g., slowing down if
>> proper acks aren't received, but it is possible to subscribe to
>> UDP/RTP sessions). This would allow the attacker to amplify the
>> attack without too much direct resource involvement.
>> 
>> 
> Yes -- but I believe for TCP this is hard, because it would imply
> being able to guess the sequence numbers. Otherwise the session won't
> even start. There are ways to guess the sequence numbers, but at
> least some of those ways involve additional cost for the attacker.
> 
>> 3. Using MIP6 home subscription to redirect traffic to the victim.
>> Of course, the risk here is that of authenticated nodes registering
>> the victim's IP address as its CoA.
>> 
>> 
>> 4. Using MIP6 RO to redirect traffic to the victim. If there is a
>> HoA test, here too, the risk is that of authenticated nodes
>> registering the victim's IP address as its CoA. The HoA test cannot
>> pass unless there is a valid binding for that node at the HA. When
>> the HoA is created with CGAs, this situation has full equivalence
>> with the home subscription. Note that I'm still not saying the
>> MN-HA authenticated state has any meaning to the CN.
>> 
>> 
> That is the crux of the matter. Whatever arrangement exists between
> the MN and its HA is invisible to the CN (under the assumption of
> talking to a random Internet host). What the CN sees with a home test
> is that the MN appears to be in control of receiving traffic at the
> home address. This is sufficient for agreeing to route traffic
> relating to that address differently, but it does not say anything
> about the existence of the node at the care of address.
> 
> Of course, if there's a problem, the CN can go and complain to the
> home network's admin. The admin may be able to find out the offending
> node and turn it off. But the victim network admin needs to talk to
> both the CN network and then indirectly the home network to get this
> started; during the design of the original RR mechanisms it was felt
> that its better to provide a mechanism that helps prevent these
> situations -- even if the network admin and authorities could sort
> out the situation later.
> 
>> amplify flooding attacks. Even though I think in practice, 2 above
>> can be used to amplify flooding attacks, if that is the intention,
>> I can buy the argument that if say, 2 is solved by other means, you
>> will still be left with the possibility of amplification via 3 and
>> 4.
>> 
>> 
> I believe 2 is harder to achieve with TCP from the attacker's point
> of view than 3 (and 4 if we didn't have RR).
> 
> I am sure there are non-TCP attacks of class 2 that are serious. My
> belief is that we should work to reduce these amplification
> vulnerabilities in the entire stack.
> 
>> However, the point I struggle with is this - as I've said above, I
>> think there is equivalence in the attack that is possible with 3
>> and 4, assuming that the HoA is based on CGAs and a HoA test is
>> done. So, if we say RR for CoA is needed, it is equally needed for
>> 3 and 4. I don't see why it is needed for 4 alone in this case.
>> 
>> 
> bootstrapping complexity). And it would have gotten us rid of problem
> #3.
> 
> enhancements. In any case, in the current deployment model of Mobile
> IPv6 there is an administrative relationship which can be used to
> shut down misbehaving nodes or even send the authorities to catch the
> guilty. I still like to have a stronger flooding amplification 
> protection for the MN - CN relationship -- particularly if it does
> not have a cost in communications latency.
> 
> --Jari
>

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Aug 2006 11:55:43 +0200

Hi Vidya.

> I don't quite agree that the above situation is any different for
> home registration vs. RO. Here's why - in both cases, let's assume
> that the victim is some random node in the internet that does not
> have any relationship with the home domain of the MN (attacker). In
> both cases, the packets arriving at the victim has the CN IP address,
> the HoA and the CoA (the victim's IP address, in this case) available
> to it. The victim additionally has the HA IP address available to it
> in the HA routed case. However, considering that the victim is a
> random node with no relationship to the home domain, it needs to
> deduce the home domain from the IP addresses and then complain. It
> can do this in both cases. In both cases, deniability is also equally
> possible, since the home domain could claim that the attacker is the
> CN in both cases.

I'll try to explain why I think the HA and CN registrations are
different wrt. how a victim could react to flooding.  At a glance:

- Deniability can, as you mention, happen in both cases.  But I don't
think it's very relevant in the HA registration case.

- Assuming that the attacker/MN and the HA do not cooperate, the victim
always has someone to send a complaint to if bidirectional tunneling is
used for flooding.  But there may not be anybody to complain at in the
RO case.

Addressing cooperations between the MN and the HA...

If the HA denies involvement in the flooding attack and assigns the
blame to the CN, then the attacker/MN and the HA cooperate.  This can
happen; there are actually 3 cases:

(1)  A "real" HA accepts the attacker's/MN's incorrect CoA during the
home registration.  The attacker/MN uses bidirectional tunneling (BT) to
flood the victim.

(2)  A "real" HA accepts the attacker's/MN's incorrect CoA during the
home registration.  The attacker/MN uses RO to flood the victim.

(3)  There is no real HA or home domain.  The attacker plays the role of
the HA during the HoA test (so the pseudo-HA and the attacker obviously
cooperate).  The flooding attack happens via RO.

I guess the point is that, in (1), the amplification is with the HA.
(The CN is also an amplifier, but that's irrelevant here.)  Since the HA
is cooperating with the MN, it may be willing to spend the effort.  But
there is not really a motivation for such an attack because there are
easier attacks with the same effect.  E.g., the HA could simply send
packets directly to the victim.

Furthermore, given the possibility of case (3), I don't see a big need
for case (2), in particular for a cooperation between the MN and the HA.
 OTOH, case (3) is really attractive because the amplification is with
the CN, and there is no need for the attacker to cooperate with a third
party.

I'd conclude that a cooperation between an attacker/MN and the HA is not
so relevant.  So let's assume for now that there is no such cooperation...

Of course, case (1) may also happen when the attacker/MN and the HA do
/not/ cooperate.  The attacker/MN then wouldn't really care about the
effort that the HA spends.  But in this case, it is in the HA's (or the
MSP's) best interest that a MN's CoA is correct, and it would certainly
disable a misbehaving MN upon complaint of a victim.

Also note that in this case, the victim has some assurance that there
really is a HA/MSP to which it can attend, because it sees the HA's IP
address in the flooding packets.

This leaves cases (2) and (3).  Case (2) is actually not the critical
one:  A victim can complain with the attacker's MSP just as it can in
case (3), even though it does not know the IP address of a HA.  More
critical is case (3), because there is no MSP to which the victim could
attend.

I think case (3) is the scenario that should concern us most, hence the
need to do the CoA test.

In summary, whether or not a MN is registered with in a "real" HA, and
howsoever secure the home registration is, is transparent to a CN.  So
the threat is that a victim may not be able to complain to anyone if the
flooding attack is based on RO, but it would be able to do so if the
attack is based on BT.  Exactly this is the reason why we have to
protect the home and correspondent registrations independently.

> really doesn't mean anything as far as I can see. 

Here is where Jari's point comes in:  a CoA test is a proactive measure,
whereas sending a complaint is only a reactive one.  The attack may long
be over when such a complaint is eventually handled.  The good thing
with the CoA test is that it /prevents/ an attack in the first place.

IMO, it would actually be good if also the HA did a CoA test.  But the
fact that the HA trusts in the CoA without a test doesn't mean that this
is very secure and should be transferred to CN registrations.

> bizzarre to me  :)  [...]

You name it. ;-)  However, that was the assumption made in RFC3775---and
the requirement for omitting the CoA in the home registration case.  See
also section 15.3 in RFC3775 and section 1.3.2 in RFC4225.

> - but, even if I made the leap to embrace that, I

Hope the text above could help a bit.

Bye,
- Christian

Narayanan, Vidya wrote:
>> being able to guess the sequence numbers. Otherwise the session
>> won't even start. There are ways to guess the sequence numbers, but
>> at least some of those ways involve additional cost for the
>> attacker.
>> 
> 
> I'd somewhat buy that :) I think spoofing the acks can be done, but
> it does involve some cost.
> 
> <snip>
> 
>> talking to a random Internet host). What the CN sees with a home
>> test is that the MN appears to be in control of receiving traffic
>> at the home address. This is sufficient for agreeing to route
>> traffic relating to that address differently, but it does not say
>> anything about the existence of the node at the care of address.
>> 
>> home network's admin. The admin may be able to find out the
>> offending node and turn it off. But the victim network admin needs
>> to talk to both the CN network and then indirectly the home network
>> to get this started; during the design of the original RR
>> mechanisms it was felt that its better to provide a mechanism that
>> helps prevent these situations -- even if the network admin and
>> authorities could sort out the situation later.
>> 
> 
> I don't quite agree that the above situation is any different for
> home registration vs. RO. Here's why - in both cases, let's assume
> that the victim is some random node in the internet that does not
> have any relationship with the home domain of the MN (attacker). In
> both cases, the packets arriving at the victim has the CN IP address,
> the HoA and the CoA (the victim's IP address, in this case) available
> to it. The victim additionally has the HA IP address available to it
> in the HA routed case. However, considering that the victim is a
> random node with no relationship to the home domain, it needs to
> deduce the home domain from the IP addresses and then complain. It
> can do this in both cases. In both cases, deniability is also equally
> possible, since the home domain could claim that the attacker is the
> CN in both cases.
> 
> call or something tangible, this is equally feasible (or not,
> actually, in my mind!) in both cases. The added availability of the
> HA IP address really doesn't mean anything as far as I can see.
> 
> 
> <snip>
> 
>>> 
>>> 
>> bootstrapping complexity). And it would have gotten us rid of
>> problem #3.
>> 
>> used to shut down misbehaving nodes or even send the authorities to
>> catch the guilty. I still like to have a stronger flooding
>> amplification protection for the MN - CN relationship --
>> particularly if it does not have a cost in communications latency.
>> 
>

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Aug 2006 13:07:53 +0200

Narayanan, Vidya wrote:
>> Good question! I do not recall if this has been analyzed during the
>> design of cga-cba draft. But taking a look at 
>> suggest what address to use. I'm not sure the draft says anything
>> about discovering the prefix first before suggesting an address
>> (which would be needed for CGAs), but this seems in general
>> possible in IKEv2. Vijay, are you listening?
> 
> whether this has any implication for the home bindings itself - i.e.,
> if the HA knows that this is a CGA-based HoA and if it needs to be
> asserted via a signature, etc. For the moment, I think I can look at
> it both ways :) But, this needs to be thought through further.

That's very true.

>From a security perspective, I don't currently see a requirement for the
HA to know that the HoA is CGA-based, given that all MN-HA security is
IPsec-based:

- During bootstrapping, the HA authenticates the MN, assigns or accepts
a HoA, and binds the HoA to the MN's identity.

- During further binding updates, IPsec will again be used to
authenticate the MN, and HoA ownership can then be verified by looking
at the MN-HoA binding established during bootstrapping.

>From a practical standpoint, there may be a benefit for the HA to know
that the MN's HoA is CGA-based.  E.g., the same public key may be used
for the IPsec SA and for generation of the CGA-based HoA.  This may help
the HA in verifying whether the MN is authorized to use a specific HoA.
 If SEND is used on the home link, proxying the MN's CGA-based HoA would
be an issue.  But all this is actually orthogonal to the CGA-CBA
protocol IMO; I don't see it's critical.

What do you think?

- Christian

Narayanan, Vidya wrote:
>> Jari Arkko wrote:
>> 
>> Narayanan, Vidya wrote:
>> 
>>> One question regarding CGA-based HoAs - don't we need to specify
>>> how CGA-based HoAs impact home registrations? For instance, the
>> preferred
>> Good question! I do not recall if this has been analyzed during the
>> design of cga-cba draft. But taking a look at 
>> suggest what address to use. I'm not sure the draft says anything
>> about discovering the prefix first before suggesting an address
>> (which would be needed for CGAs), but this seems in general
>> possible in IKEv2. Vijay, are you listening?
>> 
> 
> whether this has any implication for the home bindings itself - i.e.,
> if the HA knows that this is a CGA-based HoA and if it needs to be
> asserted via a signature, etc. For the moment, I think I can look at
> it both ways :) But, this needs to be thought through further.
> 
> sense that if we determine that home bindings will need to change,
> that needs to be first standardized and then CGA-based RO can be
> built on top of that.
> 
> Vidya

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Aug 2006 15:37:56 +0300

Agreed.

>that the MN's HoA is CGA-based. 
>  
>
Its possible to design mechanisms that employ the same
tools also for the home agent registrations, or use the
help of the home agent in the RO process. Such mechanisms
would likely have some advantages. OTOH, there is also
some value in keeping the two RO and HA registration
mechanisms separate. E.g., you don't have to sync HA and
MN code updates. IKEv2, auth option, and RFC 3776 all
can support CGAs, though some with extra config effort.

--Jari

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 15 Aug 2006 09:47:57 -0700

> >HA to know that the HoA is CGA-based, given that all MN-HA security is

I am confused by this and trying to understand the 
statement.  Doesn't this really depend on the security 
requirements?  CGAs and secure channels (IPsec SA) provide very 
different things.  We might say that there are no current 
requirements for HoA authorization and I can buy that, but saying 
that the presence of an IPsec-based secure channel obviates the need 
for CGAs confuses me.  What am I missing?

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 15 Aug 2006 10:59:22 -0700

> From: Jari Arkko [mailto:[email-masked]] 
> 
> Christian Vogt wrote:
> 
> >From a security perspective, I don't currently see a requirement for 
> >the HA to know that the HoA is CGA-based, given that all 
> MN-HA security 
> >is
> >IPsec-based:
> >
> Agreed.
> 

I don't know that this is true. As we know, what we get from IPsec and
CGAs are quite orthogonal benefits. In the case where the HA assigns the
HoA via IKEv2, HoA authorization at the HA is not needed, since the HA
knows that the IPsec SA is tied to the owner of the corresponding HoA.
Now, systems that allow stateless autoconfiguration of HoAs may or may
not want to ensure that those IP addresses are authorized and verified.
If a system employs CGAs in the network, it is actually an indication
that the system deployment cares about IP address ownership
verification. In this case, it actually seems to me that the HA being
able to verify the CGA would be very valuable and needed. 

> Its possible to design mechanisms that employ the same tools 
> also for the home agent registrations, or use the help of the 
> home agent in the RO process. Such mechanisms would likely 
> have some advantages. 

Yes, I agree with the above. For this purpose, I think we should analyze
this further to see how best RO can be actually optimized. Actually,
considering all of this is why I suggested that if we want to get an RFC
on the cga-cba work now, it should preferably be experimental, so that,
we can move it to PS after we fully analyze the space and are convinced
this is optimized in the best possible way. 

> OTOH, there is also some value in 
> keeping the two RO and HA registration mechanisms separate. 
> E.g., you don't have to sync HA and MN code updates. IKEv2, 
> auth option, and RFC 3776 all can support CGAs, though some 
> with extra config effort.
> 

Given that MIP6 hasn't seen much deployment yet and that RO is not even
considered in the pipeline yet in most planned MIP6 deployments even, I
am not so concerned about code updates. I think we should work towards
getting a fully optimized solution, so that RO in general starts looking
more attractive than it currently is. 

Vidya

---

From: Wassim Haddad <[email-masked]>
Date: Tue, 15 Aug 2006 21:52:40 +0300 (EEST)

> able to verify the CGA would be very valuable and needed.

=> Perhaps "very" is a strong word. Can you please clarify why?
I still fail to understand why if the MN (wanting to use RO mode with the
CN) decides to use CGA with the CN then enabling the HA to verify the CGA
is very valuable? Do you have any particular threat in mind? If not, can
you please point to the advantage?

> > >From a practical standpoint, there may be a benefit for the
> > HA to know that the MN's HoA is CGA-based.
> > >
> this further to see how best RO can be actually optimized.

=> This sounds very general to me (especially that OMIPv6_CGA_CBA is
about the RO mode only). The goals that OMIPv6 aims to achieve are
clearly stated in the draft and the draft also explains why and how these
goals have been achieved. I'd be very interested if you can please clarify
what exactly you see as a problem in the RO mode (only) and would like to
see optimized?

> more attractive than it currently is.

=> Again this sems very general. Please clarify more.
Note that other *additional* optimization (which are directly or
indirectly connected to the mobility) are already "ongoing" work.

Wassim H.

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Aug 2006 20:58:35 +0200

Hi Lakshminath,

we do HoA authorization in any case.  The question is how:

(a)  According to RFC 3775, the HA binds the MN's HoA to the IPsec SA
during bootstrapping and re-verifies the HoA whenever it receives a BU
from the MN.

(b)  An alternative to this would be to have the HA verify the MN's HoA
based on a CGA property.  This is what Vidya brought in.

Given that approach (a) already exists for HoA verification (it's the
default), there is actually no strong need for an additional approach
(b), although it may be handy in some deployments.

Best,
- Christian

Lakshminath Dondeti wrote:
>>> From a security perspective, I don't currently see a requirement 
>>> for the HA to know that the HoA is CGA-based, given that all 
>>> MN-HA security is IPsec-based:
>> 
>> Agreed.
> 
> I am confused by this and trying to understand the statement.
> Doesn't this really depend on the security requirements?  CGAs and
> secure channels (IPsec SA) provide very different things.  We might
> say that there are no current requirements for HoA authorization and
> I can buy that, but saying that the presence of an IPsec-based secure
> channel obviates the need for CGAs confuses me.  What am I missing?
> 
> regards, Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 15 Aug 2006 12:09:52 -0700

>during bootstrapping and re-verifies the HoA whenever it receives a BU

Here's my take on it.  If at bootstrapping, the HA makes the leap (no 
way to always verify the HoA claim if the MN picks the HoA, but 
doesn't provide CGA assertion), yeah, you are right.  Although, I am 
still puzzled by your use of the word authorization in case of (a).

I am trying to make sure that the separation between actual address 
authorization (this is case b) and re-verification based on initial 
acceptance of an unverifiable claim (case a) is clear.  If all MNs 
use CGAs, the burden on a misbehaving MN is substantially high, in 
that it needs to find a collision to claim someone else's address.

>(b), although it may be handy in some deployments.

In your view, what is the upside of CGAs in this scenario.

regards,
Lakshminath

---

From: Jari Arkko <[email-masked]>
Date: Tue, 15 Aug 2006 22:09:49 +0300

>I'd somewhat buy that  :)  I think spoofing the acks can be done, but it

Lets talk about this in more detail. To get a flooding attack
with TCP, you need to open a TCP session on behalf of
someone else i.e. using a spoofed source address. Just
sending a SYN is insufficient, because the TCP session
will not start by itself unless you respond to the reply.
For most applications you would also have to be able to
send some initial data, e.g., HTTP GET. Finally, to get
an efficient attack you would need to keep sending at least
some ACKs so that TCP gets to a higher speed.

For some TCP implementations, it was possible for the
attacker to first detect what operating system and
version the reflector node uses, open one TCP session
from the attacker's true IP address, and then guess
what initial sequence number the *next*, spoofed
session gets.

However, modern implementations should use a
randomized initial sequence number which defeats
this attack. I do not have a good estimate of how
widely this has been implemented and turned on,
but I believe it is quite widespread. With
randomization, the attacker would have to
send a large number of packets to succeed
in hitting the right number. For some spoofing
attacks it makes sense for an attacker to spend
such an effort -- but not when it wants to flood
the victim.

It is also necessary to avoid the victim node's
RST responses from disabling the attack. (See
RFC 1948.)

Based on the above, I think we have reasonable
protection against using TCP in flooding attacks.
But I don't dispute the fact that there's probably
a fair number of other situations where such
attacks are possible. And we have older TCP
implementations (but that situation should
improve over time).

----

One more follow-up: what the MIPSHOP document does
is an improvement over the existing Mobile IPv6 mechanism.
But it does not change the fundamental principles of the
base protocol, such as whether there should be
amplification/flooding attack protection in the RO
part. I would suggest that if you believe that a
change is needed in this respect we open another
discussion about that. That discussion is bigger
than the fate of a single optimization.

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Aug 2006 21:35:05 +0200

Narayanan, Vidya wrote:
> I don't know that this is true. As we know, what we get from IPsec 
> and CGAs are quite orthogonal benefits. In the case where the HA 
> assigns the HoA via IKEv2, HoA authorization at the HA is not needed,
>  since the HA knows that the IPsec SA is tied to the owner of the 
> corresponding HoA. Now, systems that allow stateless 
> autoconfiguration of HoAs may or may not want to ensure that those IP
>  addresses are authorized and verified. If a system employs CGAs in 
> the network, it is actually an indication that the system deployment 
> cares about IP address ownership verification. In this case, it 
> actually seems to me that the HA being able to verify the CGA would 
> be very valuable and needed.

You are raising an interesting point:  Whether the HA should verify that
the MN is authorized to /pick/ a particular /new/ HoA from the home prefix.

This is actually a different aspect of "HoA authorization" than ensuring
that a MN is live at a /given/ HoA -- and that it is therefore save to
redirect packets from this HoA to a CoA of the same MN.

I'd argue that, while the 2nd aspect is fundamental for mobility
security, the 1st aspect calls for proxy SEND, which could then combined
with Mobile IPv6 as you say.  And while the 2nd aspect is crucial for
the CGA-CBA protocol, I don't think there is a requirement for the 1st
aspect in the protocol.

Does this sound reasonable?

>>> From a practical standpoint, there may be a benefit for the HA to
>>> know that the MN's HoA is CGA-based.
>> 
>> Its possible to design mechanisms that employ the same tools also 
>> for the home agent registrations, or use the help of the home agent
>>  in the RO process. Such mechanisms would likely have some 
>> advantages.
> 
> Yes, I agree with the above. For this purpose, I think we should 
> analyze this further to see how best RO can be actually optimized. 
> Actually, considering all of this is why I suggested that if we want 
> to get an RFC on the cga-cba work now, it should preferably be 
> experimental, so that, we can move it to PS after we fully analyze 
> the space and are convinced this is optimized in the best possible 
> way.
> 
>> OTOH, there is also some value in keeping the two RO and HA 
>> registration mechanisms separate. E.g., you don't have to sync HA 
>> and MN code updates. IKEv2, auth option, and RFC 3776 all can 
>> support CGAs, though some with extra config effort.
> 
> Given that MIP6 hasn't seen much deployment yet and that RO is not 
> even considered in the pipeline yet in most planned MIP6 deployments 
> even, I am not so concerned about code updates. I think we should 
> work towards getting a fully optimized solution, so that RO in 
> general starts looking more attractive than it currently is.

Hmm, at this point I'm pretty much convinced that, if the HA would
verify the CGA property of the MN's HoA, that would actually not give
any benefit to RO.  It would certainly have its own uses.  But it would
be an orthogonal mechanism with orthogonal objectives (see above).

Having said that, IMO we should keep the two things separate as Jari
suggested.  All the more because the HoA verification at the HA seems to
 involve a proxy SEND mechanism which may not be so well understood at
this time as the pieces we need for the current CGA-CBA protocol.

Ciao,
- Christian

Narayanan, Vidya wrote:
> 
> 
>> -----Original Message----- From: Jari Arkko 
>> [mailto:[email-masked]]
>> 
>> Christian Vogt wrote:
>> 
>>> is IPsec-based:
> I don't know that this is true. As we know, what we get from IPsec 
> and CGAs are quite orthogonal benefits. In the case where the HA 
> assigns the HoA via IKEv2, HoA authorization at the HA is not needed,
>  since the HA knows that the IPsec SA is tied to the owner of the 
> corresponding HoA. Now, systems that allow stateless 
> autoconfiguration of HoAs may or may not want to ensure that those IP
>  addresses are authorized and verified. If a system employs CGAs in 
> the network, it is actually an indication that the system deployment 
> cares about IP address ownership verification. In this case, it 
> actually seems to me that the HA being able to verify the CGA would 
> be very valuable and needed.
> 
> 
>> Its possible to design mechanisms that employ the same tools also 
>> for the home agent registrations, or use the help of the home agent
>>  in the RO process. Such mechanisms would likely have some 
>> advantages.
> 
> Yes, I agree with the above. For this purpose, I think we should 
> analyze this further to see how best RO can be actually optimized. 
> Actually, considering all of this is why I suggested that if we want 
> to get an RFC on the cga-cba work now, it should preferably be 
> experimental, so that, we can move it to PS after we fully analyze 
> the space and are convinced this is optimized in the best possible 
> way.
> 
>> OTOH, there is also some value in keeping the two RO and HA 
>> registration mechanisms separate. E.g., you don't have to sync HA 
>> and MN code updates. IKEv2, auth option, and RFC 3776 all can 
>> support CGAs, though some with extra config effort.
>> 
> 
> Given that MIP6 hasn't seen much deployment yet and that RO is not 
> even considered in the pipeline yet in most planned MIP6 deployments 
> even, I am not so concerned about code updates. I think we should 
> work towards getting a fully optimized solution, so that RO in 
> general starts looking more attractive than it currently is.
> 
> Vidya

---

From: Christian Vogt <[email-masked]>
Date: Tue, 15 Aug 2006 21:41:32 +0200

Lakshminath,

I think we are actually talking about the same thing.  Can you take a
look at the email that I sent to Vidya a minute ago?  Maybe that
clarifies things a bit.

Alright, take care,

- Christian

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 15 Aug 2006 11:09:32 -0700

> not want to ensure that those IP addresses are authorized and verified.

lets take HoA auto-configuration.

when the MN proposes a home address, the HA checks if
the address has been claimed by/allocated to some
other mobile node. if nobody else is using that home
address, the MN is free to use the address.

if somebody else does want to use the same home
address later on, the HA will reject the request and
allocate a new home address for the MN.

> able to verify the CGA would be very valuable and needed. 

sure. but in this case, CGA-based home addresses do
not add much.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 18 Aug 2006 11:26:13 -0700

Hi Christian,
Getting back to this thread again :) Please see inline below. 

> 
> Another thing is that there may actually be no home agent and 
> home domain admin which a victim could contact.  (I mentioned 
> this in the previous email, but I guess it was lost in the 
> noise.)  E.g., an attacker may attach to a public WLAN, 
> acquire a (possibly temporary) IP address, and use this IP 
> address as a HoA in combination with a false CoA.  The 
> attacker itself would then play the HA part during the HoA test.
> 

I thought I had addressed this in one of my emails, but perhaps I
hadn't. If we assume that an attacker can fake an HA (which includes,
among other things, injecting routes for the serving fake home subnet
into the IGP/EGP so that the HoA test can occur correctly), I would also
assume that it is equally feasible for the attacker to intercept the CoA
test messages between the CN and the victim and spoof the CoA test. In
fact, interception and spoofing of messages is potentially simpler than
injecting routes into OSPF or BGP. 

Would you agree? 

Regards,
Vidya

> Of course, the HoA test would in this case guarantee the 
> attacker's reachability of the alleged "HoA", and hence a 
> victim could theoretically track the attacker down by 
> contacting the public WLAN provider.  But there is no clear 
> and, more importantly, fast procedure that the victim could follow.
> 
> Also note that the business relationship between the attacker 
> and the public WLAN provider may only be of temporary nature 
> (e.g., an hourly subscription).
>

---

From: Christian Vogt <[email-masked]>
Date: Sat, 19 Aug 2006 00:13:26 +0200

Vidya,

the attack I was describing is different:  Here the (flooding) attacker
does not use a fake home address, but it uses its current on-link IP
address as a home address.

E.g., the attacker attaches to a public WLAN, receives an RA with prefix
P, autoconfigures an IP address A with prefix P, and uses A as the IP
source address (i.e., the home address) in a HoTI which it sends to the
CN.  The HoT goes back to A, where the attacker can obviously receive
the message.  So the HoA test works fine, and the CN thinks that the
HoTI/HoT exchange went through an HA.

Now, why would an attacker want to do this?  A plausible reason would be
because it wants to redirect traffic to a particular victim node.  Hence
the attacker uses the victim node's IP address B as its CoA, and asks
the CN to send packets to B.

If A is on the path from the CN to B, then the attacker is able to pass
the CoA test.  But then the CN's packets will also hit the attacker
itself, so I don't see a good motivation for such an attack. Otherwise, 
if A is not on the path from the CN to B, then a flooding
attack against B would be more attractive (from the attacker's point of
view).  But the attacker cannot pass the CoA test in such a situation.

The point I was trying to make relates to the HoA test:  Whether or not
a real HA exists, and whether the HoA is with the HA or with the
attacker itself, doesn't matter from the perspective of the CN.

FWIW, IMO this is not a weakness of the HoA test.  The purpose of the
HoA test is solely to verify reachability at the HoA, and the test
meets this objective quite well.  I don't think it would help if the CN
could determine from the HoTI/HoT exchange whether a real HA exists or
not (given that we do not assume a security/trust relationship between
the HA and the CN).

Getting to your question about OSPF/BGP spoofing:  I do agree that we
have a serious problem if an attacker is able to forge OSPF or BGP
messages.  But as outlined above, OSPF/BGP spoofing is not necessary to
spoof the HoA test.  And obviously it is also not the right thing for
spoofing the CoA:  Advertising the CoA prefix through a routing
protocol is really the opposite of what a flooding attacker would want
to do.  After all, its intent is to direct packet not to itself, but to
a victim.

Besides, IMO, OSPF or BGP spoofing is a threat that is orthogonal to
mobility.  It is true that an attacker capable to do this is in a
position to circumvent the HoA test.  But such an attacker can anyway
steal other node's IP addresses arbitrarily.

Ok, take care,
and have a good week end!

- Christian

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

>> (e.g., an hourly subscription).

----------------------------------------------------------------
This message was sent using ATIS-Webmail: http://www.atis.uka.de

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 18 Aug 2006 15:25:17 -0700

Hi Christian,
Thanks for the prompt response and the clarification. I think I got
confused by your earlier statement about the attacker playing the HA
part. I see your point now - it is really about being able to do
correspondent registrations independently, with no real home
registrations, so to say. That is an interesting aspect - I will think
more about it. 

I have to read a few other emails of yours more carefully as well. Also,
Jari had sent some emails on this thread that I need to read in detail.
I will read and respond next week. 

Have a good weekend. 

Regards,
Vidya

> Sent: Friday, August 18, 2006 3:13 PM
> To: Narayanan, Vidya
> Cc: Jari Arkko; Wassim Haddad; [email-masked]
> Subject: RE: Flooding Attacks and MIP6 (was RE: [Mipshop] 
> Review ofdraft-arkko-mipshop-cga-cba-04)
> 
> Vidya,
> 
> the attack I was describing is different:  Here the 
> (flooding) attacker does not use a fake home address, but it 
> uses its current on-link IP address as a home address.
> 
> E.g., the attacker attaches to a public WLAN, receives an RA 
> with prefix P, autoconfigures an IP address A with prefix P, 
> and uses A as the IP source address (i.e., the home address) 
> in a HoTI which it sends to the CN.  The HoT goes back to A, 
> where the attacker can obviously receive the message.  So the 
> HoA test works fine, and the CN thinks that the HoTI/HoT 
> exchange went through an HA.
> 
> Now, why would an attacker want to do this?  A plausible 
> reason would be because it wants to redirect traffic to a 
> particular victim node.  Hence the attacker uses the victim 
> node's IP address B as its CoA, and asks the CN to send packets to B.
> 
> If A is on the path from the CN to B, then the attacker is 
> able to pass the CoA test.  But then the CN's packets will 
> also hit the attacker itself, so I don't see a good 
> motivation for such an attack. Otherwise, if A is not on the 
> path from the CN to B, then a flooding attack against B would 
> be more attractive (from the attacker's point of view).  But 
> the attacker cannot pass the CoA test in such a situation.
> 
> The point I was trying to make relates to the HoA test:  
> Whether or not a real HA exists, and whether the HoA is with 
> the HA or with the attacker itself, doesn't matter from the 
> perspective of the CN.
> 
> FWIW, IMO this is not a weakness of the HoA test.  The 
> purpose of the HoA test is solely to verify reachability at 
> the HoA, and the test meets this objective quite well.  I 
> don't think it would help if the CN could determine from the 
> HoTI/HoT exchange whether a real HA exists or not (given that 
> we do not assume a security/trust relationship between the HA 
> and the CN).
> 
> Getting to your question about OSPF/BGP spoofing:  I do agree 
> that we have a serious problem if an attacker is able to 
> forge OSPF or BGP messages.  But as outlined above, OSPF/BGP 
> spoofing is not necessary to spoof the HoA test.  And 
> obviously it is also not the right thing for spoofing the 
> CoA:  Advertising the CoA prefix through a routing protocol 
> is really the opposite of what a flooding attacker would want 
> to do.  After all, its intent is to direct packet not to 
> itself, but to a victim.
> 
> Besides, IMO, OSPF or BGP spoofing is a threat that is 
> orthogonal to mobility.  It is true that an attacker capable 
> to do this is in a position to circumvent the HoA test.  But 
> such an attacker can anyway steal other node's IP addresses 
> arbitrarily.
> 
> Ok, take care,
> >> previous email, but I guess it was lost in the
> >> noise.)  E.g., an attacker may attach to a public WLAN, acquire a 
> >> (possibly temporary) IP address, and use this IP address 
> as a HoA in 
> >> combination with a false CoA.  The attacker itself would then play 
> >> the HA part during the HoA test.
> >>
> >
> > into the IGP/EGP so that the HoA test can occur correctly), I would 
> > also assume that it is equally feasible for the attacker to 
> intercept 
> > the CoA test messages between the CN and the victim and 
> spoof the CoA 
> > test. In fact, interception and spoofing of messages is potentially 
> > simpler than injecting routes into OSPF or BGP.
> >
> > Would you agree?
> >
> > Regards,
> > Vidya
> >
> attacker's 
> >> provider.  But there is no clear and, more importantly, fast 
> >> procedure that the victim could follow.
> >>