Subject: RE: [mobile-ip] fastv6 and CoAs

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 18 Sep 2002 04:30:54 +0200

I've been struggling to keep up with the 
discussion but from what I saw, it seems that
there was a minor detail that was overlooked
or I missed it. 
When we discuss whether the MN should keep its
old CoA in the new subnet, we obviously assume 
that the tunnel is terminated at the new AR, right?
If so, are we sure that ingress filtering can handle
this? From what I know about existing routers, it seems
that some of them do not support dynamic or even manual
configuration of the ingress filter and automatically 
take the prefix(es) that they advertise as the default. 
Can someone confirm if this is true or false? 
If this is true, then the MN would not be able to send
traffic using its old CoA. 

In fact, regardless of this issue, on an ethernet, how 
can the AR be sure if it's allowing _the_ MN to get its
traffic through or if someone else is spoofing that address
to launch attacks without being traced to its real location? 

Hesham

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 18 Sep 2002 10:17:17 -0700

> take the prefix(es) that they advertise as the default.

Yes, you would compare the address handed out for this
PPP session with the care of address in the packet. 
But you are already doiing quite a few new things when
you implement FMIPv6. In this case, The oAR based on L2 trigger  
needs to set up a source route for oCoA pointing at the tunnel.
And the nAR based on the L2 trigger needs to set up an
IP interface for the MN with oCoA so that when it decapsulates
from the tunnel, it can send packets over this interface to
the MN. Now on this interface, you will accept packets only
with this oCoA. So, where is the problem ?

> to launch attacks without being traced to its real location? 
I thought the nAR gets the oCoA from the oAR and trusts the
oAR which in turn must have authenticated the MN before.

-mohan

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 18 Sep 2002 19:20:15 +0200

>oAR which in turn must have authenticated the MN before.

=> Yes, but what stops a Bad Guy from spoofing that
address and the MN's MAC addres if he has to, to
launch attacks without being detected (from a location
point of view). 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 18 Sep 2002 18:53:49 +0200

> Just as with responding to SolPrRtAdv by sending a PrRtAdv 
  > and HI/HaCK, this
  > would require a change in the router. 

=> Well, 

The router has the L2 
  > address via the
  > HI/HaCK, it would use that to determine whether or not to 
  > tunnel the packet.

=> 

  > 
  > 
  >             jak
  > 
  > ----- Original Message -----
  > From: "Hesham Soliman (EAB)" <[email-masked]>
  > To: "'James Kempf'" <[email-masked]>; "Rajeev Koodli"
  > <[email-masked]>
  > Cc: <[email-masked]>
  > Sent: Tuesday, September 17, 2002 7:30 PM
  > Subject: RE: [mobile-ip] fastv6 and CoAs
  > 
  >

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Fri, 20 Sep 2002 03:49:58 +0200

> > => So let me see if we're on the same page:
  > > Following your suggestion, a malicious node (that has nothing to
  > > do with FMIPv6) that happened to know the neighbouring
  > > prefixes, can spoof them and launch attacks on other nodes
  > > without being traced to the right link. Is this correct?
  > >
  > 
  > Not exactly since the Previous router can supply the exact
  > (previous) IP address of the MN. Of course a malicious node
  > could spoof that address itself, but that probability is smaller.

=> The attacker doesn't need to guess, on a multiaccess
link this can be seen.

  > Furthermore, if we keep the tunnel lifetime short enough, the
  > incentive for launching an improbable "attack" is decreased even
  > more.

=> Yes, but with many MNs moving we would suddenly have 
many IP addresses to use. I don't have numbers obviously
and we don't know how long the lifetime of the tunnel will
be either.

  > 
  > >
  > > or else, with
  > >   > an API permitting, through HI/Hack.
  > >
  > > => I don't understand what you mean by this.
  > >
  > 
  > I mean program the prefixes based on HI/HAck exchange.

=> Sure, that was my assumption. 

Hesham

---

From: "James Kempf" <[email-masked]>
Date: Fri, 20 Sep 2002 09:24:53 -0700

> incentive for launching an improbable "attack" is decreased even

Having a malicious node spoof a previous CoA is no different than having a
malicious node spoof a CoA on the current subnet.

The router needs to do ingress filtering by address rather than by prefix. But
it is doing that anyway in effect for packets coming in through the tunnel.

            jak

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Sat, 21 Sep 2002 23:28:19 +0200

> => I understood that, but that does not stop anyone
> from spoofing the MAC and IP address. The actual
> _values_ will be correct, but there is no way of
> mapping them to the _right_ machine. In other words,
> how does the AR know if these values are coming from the
> MN that the oAR was referring to, and not some other node?
>

I guess what I am saying is that it doesn't, 

=> ok so we agree on this.

but absent any specific
security
measures on the local link, the same problem applies to any node on the
local
link, regardless of whether it has made a handover or not.

=> Not really, if you have ingree filtering
this can't happen. Of course one can spoof 
other nodes' IP addresses, but that's not 
something ingress filtering was designed to avoid. 

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Tue, 24 Sep 2002 23:01:20 +0200

> > => But you're just confirming the need for following
  > > ingress filtering recommendations, right?
  > > In MIPv6 we don't want to reverse tunnel if RO is used.
  > 
  > I am confirming that there is a standards precedence for
  > supporting topologically inconsistent addresses, using reverse
  > tunneling. Ironically, in order to support RO in MIPv6, you
  > would have to allow use of previous CoA (until RR is done)
  > and reverse tunnel to previous AR.

=> there is a precedence in the standard because there
was a need for topologically incorrect addresses. We
don't need to apply it here unless we have to.

  > > => An attacker doing DoS attacks doesn't need to worry
  > > about any windows. He just snoops the link and pick
  > > addresses and send away, if they go through the AR
  > > then great, if they don't it doesn't matter.
  > >
  > >
  > 
  > So, if the window is not open, there is no damage to an
  > external network. And, may be you can trace the attacker
  > in that case :-)

=> You're missing my point I think. The attacker
will keep sending regardless of whether the window
is open or not. The window will eventually open
(I hope) and packets will get through. 
If you know of a way of tracing the attacker on 
a WLAN that would be helpful in this discussion.

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 25 Sep 2002 06:32:05 +0200

> Right, but this doesn't have anything to do with ingress 
  > filtering. The attacker
  > is using legitimate addresses, not addresses with an 
  > improper prefix. My
  > understanding of ingress filtering (which may not match 
  > yours) is that it is
  > designed to prevent an attack that uses a prefix different 
  > from the one being
  > routed on the link. Like a MN sending a packet with its 
  > home address from the
  > foreign link. That's why reverse tunneling was put into 
  > MIPv4, as Rajeev
  > mentioned.
  > 
  > It is because there is currently no way to tie down a 
  > particular IP address to a
  > particular MAC address (presuming the MAC address can't be 
  > spoofed). This
  > doesn't have anything to do with fast handover, it is a 
  > general property of
  > multiaccess links. 

=> My comment was that if there was no fast handover
then we are limited by the prefix located on that link.
Sure, the same attack can be done but at least the location
(link) will be known, which is not the case when fast handovers
are used. 
A later mail from Alper made sense to me (about tracking the
address to the oAR) although I don't know if ARs will log
every address as he suggested. 
But I still have another question related to having more
than one AR on-link. I'll have to think about that first
to see if it's an issue.

Hesham

---

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 24 Sep 2002 23:30:18 -0500

Hello Hesham,
Please find my inline reply.
Regards,
Ajoy 

-----Original Message-----
From: Hesham Soliman (EAB) [mailto:[email-masked]]
Sent: Tuesday, September 24, 2002 4:01 PM
To: 'Rajeev Koodli'
Cc: 'James Kempf'; [email-masked]
Subject: RE: [mobile-ip] fastv6 and CoAs

AJOY-> I think someone else might have made this point
before, but anyhow I would like to repeat this once
again. I think this problem can be solved by reverse
tunneling. The reverse tunneling would allow all the 
spoofed packets to pass though the firewall of new 
access network, but the same packets will be dropped
by the firewall of old access network. Hence, it 
will be difficult to launch DoS
attack without getting caught. Am I missing anything
here?

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 25 Sep 2002 06:51:07 +0200

Ajoy, 

You're right, this should fix it.

Hesham

  > From: Singh Ajoy-ASINGH1 [mailto:[email-masked]]
  > Sent: Wednesday, September 25, 2002 6:30 AM
  > To: 'Hesham Soliman (EAB)'; 'Rajeev Koodli'

---

From: "Grimminger Jochen" <[email-masked]>
Date: Wed, 25 Sep 2002 14:34:13 +0200

Hallo,

probably it's helpful in the security discussion ... is anybody on the list
involved into HIP Host Identity Payload or at least knows  the actual status
of the WG (if still existing) ? They should have thought about something
similar
already ... what have been their ideas ?

Regards

Jochen

----------------------------------------------------------------------------
-------
Jochen Grimminger

( phone: +49  89 636 - 41740
2  fax:  +49  89 636 - 51115
, e-mail: [email-masked]

*    Siemens AG
Corporate Technology
Otto Hahn Ring 6
81730 München - Germany

----------------------------------------------------------------------------
-------

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 25 Sep 2002 11:08:49 -0700

Ok. Perhaps we should  mention the detail about ingress filtering
in the  draft.

-mohan

> From: James Kempf [mailto:[email-masked]] 
> Sent: Tuesday, September 24, 2002 9:00 PM
> To: Mohan Parthasarathy; Hesham Soliman (EAB); Rajeev Koodli
> Cc: [email-masked]
> Subject: Re: [mobile-ip] fastv6 and CoAs
> 
> 
> Mohan,
> 
> We're talking about making changes in the access router. 
> Routers today don't support PrxyRtSol or PrxyRtAdv.
> 
>             jak
> 
> From: "Mohan Parthasarathy" <[email-masked]>
> To: "Hesham Soliman (EAB)" <[email-masked]>; 
> "Rajeev Koodli" <[email-masked]>
> Cc: "James Kempf" <[email-masked]>; 
> <[email-masked]>
> Sent: Tuesday, September 24, 2002 12:45 PM
> Is this a new requirement that ingress filtering should check 
> both the CoA and the Mac address ? According to RFC2267, you 
> are supposed to just check the IP address and I assume that 
> is what most routers do.
> 
> -mohan
> 
> 
> >   >
> >   > I don't think we are breaking it any more than
> >   > allowing HoA and reverse tunneling
> >   > from FA in MIPv4. Are we ?
> >
> > => Do networks deploying MIPv4 run ingress filtering
> > if there was no reverse tunnelling from the FA?
> >
> > I don't think MIPv4 is a good example :)
> >
> >   > I think it is harder to spoof an arbitrary combination
> >   > of off-link prefix and iid.
> >   > Here is what a malicious node needs to do I think.
> >   >
> >   > - spoof the off-link prefix. How ? by monitoring the traffic ?
> >   >    How is prefix length determined ?
> >
> > => Who cares? It's spoofing the whole thing. Anyway,
> > the IPv6 prefix length is 64.
> >
> > The off-link prefix
> >   >    is never advertised on the new router's link. If the attacker
> >   >    moved from the link where the off-link prefix is valid,
> >   >    then he would know the off-link prefix.
> >
> > => He doesn't need to, see above.
> >
> >   > - spoof the MAC address. How ? Through ND.
> >
> > => Monitoring traffic. No need for ND.
> >
> >   > - keep looking for the "window" to open. That is, guess when
> >   >    the new router would allow traffic with previous CoA.
> >   > - send packets with the spoofed address
> >   >
> >   > This is hard work with questionable incentives, especially if
> >   > the tunnel lifetime is kept short.
> >
> > => As I said earlier, in a real situation there is probably 
> more than 
> > one MN doing a handover, so there is more than one of those 
> addresses.
> >
> > Hesham
> >
> 
> 
>