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 PROTECTED]]
> Sent: Friday, April 20, 2001 8:53 AM
> To: Christian Huitema
> Cc: Edward Vielmetti; [EMAIL PROTECTED]; ietf-
> [EMAIL PROTECTED]
> 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 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
