Subject: RE: Source addresses, DDoS prevention and ingress filtering

From: "Christian Huitema" <[email-masked]>
Date: Fri, 20 Apr 2001 09:38:34 -0700

I believe that the source address should be defined as "the address at
which the source would like to receive replies to this message." In the
case of a mobile host, there is value in getting replies either at your
transient address or at the permanent address -- it basically depends on
the circumstance, just like multi-homing, and things would be simpler if
both were allowed.

Mobile networks could also be thought off as multi-homed networks. The
mobile router could in theory advertise two prefixes, one based on a
"permanent" connection maintain via some tunneling mechanism and one
based on the "transient" connection. Indeed, this can also be thought
off as an exercise in fast network renumbering. Say a car is traveling
at 180 km/h on a freeway, and a cell is 1 km wide -- it stays in any
given cell for 20 seconds; you may have to renumber the network every 20
seconds. That seems a more interesting problem to solve than source
address filtering, and I would in fact rather not make it even more
complex by throwing in mandatory source address filtering...

-- Christian Huitema

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, April 20, 2001 8:53 AM
> To: Christian Huitema
> Cc: Edward Vielmetti; [email-masked]; ietf-
> [email-masked]
> Subject: RE: Source addresses, DDoS prevention and ingress filtering
> 
> 
> Christian,
> 
> So what is your opinion of using the topologically
> "incorrect" IP address as the source when, say, a
> mobile node is away from home? It is still, after
> all, return routable via its home address, so it's
> not completely bogus on its face. In fact, it's no
> different than the multihomed case. However, right
> now as currently constituted in mobileipv6 two
> things will be extremely problematic:
> 
> 1) The stationary host behind a mobile router I brought
>    up before (no way to know what is "correct")
> 
> 2) RSVP reservations upon change of CoA will need
>    to create a completely new reservation since
>    the filterspec must change. If the classifier
>    used the home address, the reservation could
>    converge locally which would be beneficial.
> 
> There may well be other things which break because
> of the expectation of a fixed source address.
> 
> 		    Mike
> 
> Christian Huitema writes:
>  > Ed,
>  >
>  > I have seen over the past years many knee-jerk reactions to attacks
> that
>  > essentially followed the model you are describing. An example is to
cut
>  > ICMP because it is used in some attacks; the proposal to "verify
> unicast
>  > reverse-path" is another. The problem is that a number of these
> defenses
>  > amount to cutting your nose in order to cure the common cold. For
>  > example, cutting ICMP also suppresses efficient path MTU discovery;
>  > random reverse path verification kills multi-homing and makes
mobility
>  > much harder. This is compelled by the evolutionary nature of the
>  > attacks: many of the ICMP attacks can be replicated over UDP, and
thus
>  > you find sites cutting UDP as well -- and here goes voice over IP;
in
>  > fact, I could also mount attacks by sending TCP packets outside the
>  > context of connections -- think of the consequences of various
router
>  > protections for that...
>  >
>  > The "verify unicast" defense looks good on paper, but if you
analyze
> it,
>  > it requires quasi universal deployment to make a difference. This
is
> not
>  > simpler than deploying protection against forged addresses in the
>  > potential targets, mostly large web servers. In fact, the number of
>  > targets is probably lower than the number of "ingress routers" that
>  > would have to be upgraded. But then, there are three important
>  > differences.
>  >
>  > First, modern servers actually include protection against the
forged
>  > address attacks that you mention -- proper handling of TCP context
>  > creation and verification of the plausibility of sequence numbers
>  > provide a first line of defense; SSL or IPSEC provide further
> protection
>  > for critical systems. Routers don't include such protections today;
> they
>  > would require modification to routing protocols to describe the
>  > authorized source address in parallel to the allowed destinations,
>  > possibly additional fast-path hardware, and certainly an increased
>  > management load.
>  >
>  > Second, the protection only works if it is implemented everywhere,
and
>  > is in any case partial. As long as I cannot be sure that all
Internet
>  > routers perform the filtering, I still have to implement adequate
> server
>  > side protections. If the router can be hacked, the protection is
>  > obviously ineffective. If the egress filtering operates on broad
> ranges,
>  > say a university network, the hacker can stop using random
addresses,
>  > and instead pretend that all packets come from a single machine,
e.g.
>  > the university's web site.
>  >
>  > Third, and most important, the network based defense places the
defense
>  > burden at the wrong side of the problem. The local network is not
> really
>  > suffering from the attack; its administrators have only minor
> incentives
>  > to fix it. The one who is suffering is a remote server; there, you
have
>  > a lot of incentives to fix the problem, fix the TCP stack, deploy
> IPSEC.
>  >
>  > All in all, I wish we would not cut the node of our face. As
servers
> get
>  > hardened, the mode of attack will change. We don't want to maim the
>  > network today to protect against an attack that will not be in much
use
>  > tomorrow.
>  >
>  > -- Christian Huitema
>  >
>  >
>  >
>  > > -----Original Message-----
>  > > From: Edward Vielmetti [mailto:[email-masked]]
>  > > Sent: Thursday, April 19, 2001 9:24 PM
>  > > To: Christian Huitema
>  > > Cc: Glenn Morrow; Michael Thomas; Thomas Eklund;
>  > [email-masked];
>  > > [email-masked]
>  > > Subject: RE: Source addresses, DDoS prevention and ingress
filtering
>  > >
>  > > Christian,
>  > >
>  > > The specific threat model is a compromised host being directed
under
>  > > remote control to send a spray of packets with randomly forged
source
>  > > addresses to a victim host far away.  Intelligently throwing your
>  > local
>  > > equivalent of "ip verify unicast reverse-path" as a check in at
>  > logical
>  > > choke points on the network will *in actual practice* drop a
whole
> lot
>  > of
>  > > traffic that should be dropped.  This has important implications
for
>  > > network operators.
>  > >
>  > > This is not a security or confidentiality problem, and thus IPSEC
is
>  > > irrelevant.  It is a network integrity problem.
>  > >
>  > > Ed
>  > >
>  > > On Thu, 19 Apr 2001, Christian Huitema wrote:
>  > >
>  > > > I am not sure it is such a good idea.
>  > > >
>  > > > >From a security stand point, it is very weak. You are trusting
> that
>  > > some
>  > > > third party, at the other end of the network, will do the right
>  > thing.
>  > > > What happens if the "first hop" is compromised? And, by the
way,
>  > what
>  > > > exactly is the first hop? The wireless LAN in my home? The
Ethernet
>  > > > backbone in the same home? If you want any form of security,
you
>  > really
>  > > > have to build it yourself, e.g. by using IPSEC. The only form
of
>  > source
>  > > > address control that has a prayer of working is local, i.e.
refuse
>  > to
>  > > > accept inbound packets in your domain that pretend to already
come
>  > from
>  > > > an inside address.
>  > > >
>  > > > It is also very weak from a routing stand point. Internet
routing
> is
>  > > > anything but symmetric. The exit path from a domain depends
only on
>  > the
>  > > > destination address, not the source address; insisting on
strict
>  > control
>  > > > of the source address basically breaks multi-homing. It also
breaks
>  > > > several forms of mobility...
>  > > >
>  > > >
>  > > > > -----Original Message-----
>  > > > > From: Edward Vielmetti [mailto:[email-masked]]
>  > > > > Sent: Wednesday, April 18, 2001 10:41 AM
>  > > > > To: Glenn Morrow
>  > > > > Cc: Michael Thomas; Thomas Eklund;
[email-masked]';
>  > 'ietf-
>  > > > > [email-masked]'
>  > > > > Subject: RE: Source addresses, DDoS prevention and ingress
>  > filtering
>  > > > >
>  > > > > And you're going to mandate source filtering on the first hop
>  > across
>  > > > the
>  > > > > entire internet, how?  It's a great idea and a best common
>  > practice
>  > > > but
>  > > > > not something that can be set by fiat.
>  > > > >
>  > > > > Ed
>  > > > >
>  > > > > On Wed, 18 Apr 2001, Glenn Morrow wrote:
>  > > > >
>  > > > > > Then again if source filtering is mandated on the first hop
> this
>  > > > might
>  > > > > > eliminate the need to do filtering on other hops and this
would
>  > > > > eliminate
>  > > > > > the need to do subnet translation or tunneling by either
the MN
>  > or
>  > > > the
>  > > > > MR.
>  > > > > >
>  > > > > > -----Original Message-----
>  > > > > > From: Morrow, Glenn [RICH2:C330:EXCH]
>  > > > > > Sent: Wednesday, April 18, 2001 11:56 AM
>  > > > > > To: 'Michael Thomas'
>  > > > > > Cc: Michael Thomas; Thomas Eklund;
[email-masked]';
>  > > > > > [email-masked]'
>  > > > > > Subject: RE: Source addresses, DDoS prevention and ingress
>  > filtering
>  > > > > >
>  > > > > >
>  > > > > > Oh, I see what you were concerned about. It seems to me
that an
>  > MR
>  > > > will
>  > > > > have
>  > > > > > to tunnel or subnet translate unless it is on it's home
subnet.
>  > > > > >
>  > > > > > -----Original Message-----
>  > > > > > From: Michael Thomas [mailto:[email-masked]]
>  > > > > > Sent: Wednesday, April 18, 2001 9:49 AM
>  > > > > > To: Morrow, Glenn [RICH2:C330:EXCH]
>  > > > > > Cc: Michael Thomas; Thomas Eklund;
[email-masked]';
>  > > > > > [email-masked]'
>  > > > > > Subject: RE: Source addresses, DDoS prevention and ingress
>  > filtering
>  > > > > >
>  > > > > >
>  > > > > > Glenn Morrow writes:
>  > > > > >  > If the node behind the MR obtained its home address from
the
>  > the
>  > > > > mobile
>  > > > > >  > router's subnet, then the MN will use this as the source
> i.e.
>  > the
>  > > > > MN's
>  > > > > > home
>  > > > > >  > subnet is the MR's subnet.
>  > > > > >
>  > > > > >    Right, but when the MR's upstream router does an
>  > > > > >    RPF check... it will drop the SN's packets.
>  > > > > >
>  > > > > >  > Either way (tunneling or subnet translation), the
> topological
>  > > > > correctness
>  > > > > > is
>  > > > > >  > still maintained.
>  > > > > >
>  > > > > >    Well, that's sort of the problem. The SN doesn't
>  > > > > >    know that it's putting topologically incorrect
>  > > > > >    source address in the IP header.
>  > > > > >
>  > > > > > 		  Mike
>  > > > > >
>  > > > >
>  > > > >
>  > > > >
>  >
--------------------------------------------------------------------
>  > > > > IETF IPng Working Group Mailing List
>  > > > > IPng Home Page:
>  > http://playground.sun.com/ipng
>  > > > > FTP archive:
>  > ftp://playground.sun.com/pub/ipng
>  > > > > Direct all administrative requests to
>  > [email-masked]
>  > > > >
>  >
--------------------------------------------------------------------
--------------------------------------------------------------------
>  > IETF IPng Working Group Mailing List
>  > IPng Home Page:                      http://playground.sun.com/ipng
>  > FTP archive:                      ftp://playground.sun.com/pub/ipng
>  > Direct all administrative requests to [email-masked]
>  >
--------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2001 10:23:37 -0700 (PDT)

Christian,

This is an excellent piece of insight. As it
stands right now in MIPv6, the mobile node sending
toward the correspondent node is supposed to put
in a Home Address destination option.  This at its
base causes a number of problems, such as the
ones I've already pointed out, but also there are
yet more problems when you start to consider
mobile nodes behind mobile routers. Consider a CN
which got multiple binding updates from both the
MN and the MR: how would it know how to assemble
the routing headers in the proper order?

Perhaps we should take a lesson from SMTP and/or
SIP here. When I send a mail message, my From:
address is essentially constant. If I want the
return mail routed differently, I insert a
Reply-to: header. SIP extends this a bit more
and allows Proxies to add Record-Route to force
return signaling through intermediate nodes. There
is a very analogous situation with basic IP
routing, it seems, where routers are similar to
proxies. This should hardly be surprising.

What I'm thinking is that maybe we should consider
flipping the sense of current MIPv6 thinking:
instead of placing the CoA in the IP header,
you instead place your home address in the IP header
because it is, in fact, the way to reach you. If
you're away from home, however, or for any other
reason such as the case for multihoming, you would
place a Reply-via destination option into the
packet. The Reply-via is, in fact, the ordered set
of IP addresses that should be visited before the
home address; in other words, it's nothing more
than the explicit routing header stack. If 
intermediate nodes, such as mobile routers, could
push their addresses onto the routing header
stack, then we will have solved the other
nettlesome problem and have done it in such a way
that we can keep unwitting stationary nodes behind
a mobile router unaware of their mobility.

I believe that the security considerations are the
same, however: if we use return routability as our
basic test for correspondent nodes, this has the
same considerations, I believe. 

		     Mike