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 PROTECTED]]
> > Sent: Thursday, April 19, 2001 9:24 PM
> > To: Christian Huitema
> > Cc: Glenn Morrow; Michael Thomas; Thomas Eklund;
> [EMAIL PROTECTED];
> > [EMAIL PROTECTED]
> > 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 PROTECTED]]
> > > > Sent: Wednesday, April 18, 2001 10:41 AM
> > > > To: Glenn Morrow
> > > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]';
> 'ietf-
> > > > [EMAIL PROTECTED]'
> > > > 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 PROTECTED]';
> > > > > '[EMAIL PROTECTED]'
> > > > > 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 PROTECTED]]
> > > > > Sent: Wednesday, April 18, 2001 9:49 AM
> > > > > To: Morrow, Glenn [RICH2:C330:EXCH]
> > > > > Cc: Michael Thomas; Thomas Eklund; '[EMAIL PROTECTED]';
> > > > > '[EMAIL PROTECTED]'
> > > > > 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 PROTECTED]
> > > >
> --------------------------------------------------------------------
> > >
> >
>
> --------------------------------------------------------------------
> 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 PROTECTED]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
