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

From: Thomas Eklund <[email-masked]>
Date: Tue, 10 Apr 2001 15:39:27 +0200

Hi Pekka,
It is an interesting topic you raise.

I think though that our AAA v6 draft is a big step forward and would like to
stress at a few points.

> here we go anyway.  This message is divided in three parts: 
>   A. Discussion about source address filtering 
>   B. A comparison between source and destination addresses 
>   C. My thoughts what should be done instead 
> 
> A. Discussion about source address filtering 
> 
> Now, according to my analysis, currently there are basically three 
> functional reasons for including the source address into IPv6 
> packets. 
> 
>   1. Source addresses are needed to be able to reply to 
>      packets, such as unconnected UDP queries or TCP SYN packets. 
>   2. Source addresses are needed to be able to report 
>      back error conditions, e.g., ICMP Packet Too Big. 
>   3. Source addresses are used for identifying upper layer 
>      endpoints, e.g., to differentiate between TCP sockets. 
> 
> It is instructive to note that in the two first cases the 
> source address is really needed, but in the last case it 
> is merely a convenient piece of information that could be 
> easily replaced with something else identifying the remote 
> endpoint (compare e.g. to HIP). 
> 
> Now, mandating source address filtering attempts to add another 
> purpose for the source address; a purpose that I don't believe 
> could ever be really reliable. 

It could though be combined with the access control that we explain in the
draft

>   4. Source addresses identify the interface through 
>      which the packet was originated.  (FALSE) 
> 
> Maybe this was the original intention of the source address, 
> but to me it seems like the infrastructure has never really 
> supported this allusion.  Furthermore, it is instructive to 
> note that even with honest nodes the source addess does not 
> always identify the sender.  For example, some neighbour 
> solicitation packets carry the unspecified source address, etc. 
> Furthermore, even strict and mandatory ingress filtering does 
> not quite achieve the maxim -- if the filtering was perfect, it 
> would at most lead to a situation where the source address 
> identifies the source link of the packet, not the specific 
> interface at the link.  

I agree and this is how it is more or less solved in the draft where the
authenticated address becomes a temporary link identifier with a chance to
update the ACL filter in the router based on the authentication and
authorazation phase with the home AAA server. In other words it does not
mean so much if we use the CoA or Home Adress in respective to the protocol,
but in the draft the CoA could be seen as the authenticated "link
identifier" and my belief is that it solves a lot of the issues you raise,
perhaps not all, but a lot of them. 

And then you have to bear in mind that it is very easy to implement with
existing policy manager/ACL rule managers in existing routers.

> 
> Even further, I think that there are several reasons why 
> even trying to achieve this illusion is a bad idea. 
> 
>   a) Since source address filtering would be a piece of 
>      functionality whose malfunction does not have any immediate 
>      local effects, I have hard time believing that we would 
>      ever get even 90% coverage. 

What do you mean here? In my view it is the easiest way to secure the access
and combine it with the AAA draft where you do you authentication and
authorazation in the AAA infrastructure, and you could reuse a lot of the
software that is already running inside the routers for handling ACL rules.

>   b) Taking the trend described at the open plenary on 
>      Wednesday evening, i.e. internet turning more and more 
>      into a densely connected mesh instead of being more-or-less 
>      hierarchical tree, employing source address filtering in 
>      any other place but the ingress router would be quite hard 
>      operationally, and hard even at the ingress routers.  We have 
>      already seen this in the various multihoming discussions. 

Not if you have an option to update the ACL rules automatically that could
be done as it is described in the draft...

>   c) Being mandated (but not working properly), it would 
>      encourage people to trust the source address even more 
>      that they do today.  

Nothing strange. It is the same thing today in the mobile networks for
instance wher your identifier is an IMSI which could be compared to
something similar as a HA in case of mobile ipv6 with AAA.

> 
> B. Comparison between source and destination addresses 
> 
> IMHO, on instructive point of view is to compare the functions 
> of the source and destination addresses.  Most people seem to 
> believe, perhaps even unconsciously, that source and destination 
> addresses are functionally equivalent.  That is, it seems to be 
> common thinking that the destination address identifies the 
> destination interface(s) of the packet and the source address 
> identifies the source interface of the packet.  As we know, 
> this is not true.  Now, the question is whether we should aim 
> to make it true again (if it ever was) or should we abandon 
> that thinking altogether. 

It is already split today. The HA is the identifier of the user. But your're
right, the identifier could have several semantical meanings, some might
argue that it is a "home interface" or something else. And I would like to
see the CoA as a link identifier.

> The source address does not (currently) have any such semantics. 
> It is just set by the sender, and used by the receiver.  The only 
> case when an intermediate router cares about it is when it wants 
> to send an error report back.  However, this latter practice does 
> not seem to be such a good idea, since the source address does not 
> necessarily carry information about the real sender of the packet. 
> In short, the practise greatly eases reflection DDoS attacks, since 
> you can fairly easily employ many of the routers in the 
> infrastructure 
> to act as reflectors.  (Just mix routing headers and hop-by-hop
> options.) 

Thats why a architechure base on filtering is so easy and in the short
perspective make sense, the access lists are enforced at the access where
the aggregated amount of traffic is not overhelming.
 
> C. My thoughts what should be done instead 
> 
> I know this is a radical idea and that it is probably too late to 
> propose this, but I think that we should deprecate the source 
> address in the IPv6 header altogether.  Instead, we should use 
> a separate destination option, perhaps "Reply-To Address Destination 
> Option", whenever we assume that the recipient may not know where 
> to send the replies.  Please note that if we use end-to-end IPsec, 
> we never need to use this option, and that any other TCP packets 
> but the first SYN packet would not need to carry it either.  
> 
> Depracating the source address field from it current use would 
> free it for other purposes.  My suggestion is that the main function 
> would be to use it for _recording_ the path of the packet.  That is, 
> each router that touches the packet would (perhaps probabilistically) 
> somehow record its identity into the source address field.  Thus, 
> the source address field would no longer be a source address field 
> but a source path field.  

To be frank, this sounds like a weaker proposal than the existing ones.

You open up the routers to allow them to write into the packet (the source
path). The problem with this approach is that it scales  poorly and put more
demand on the routers not only in the access but even further up in the
aggregation, edge, core etc.

Maybe I missed your point.

Remember that I talk about packet filtering together with somthing like our
AAA v6 draft to enforce access control.

> 
> This would have several benefits.  First, those that believe 
> in ingress 
> filtering would perhaps be happy with the recorded packet path
> information. 
> Second, those not believing in ingress filtering would be happy, too, 
> since packets would not have to be dropped.  Third, one could easily 
> make the reply-to address private by including the destination option 
> within an ESP header.  Fourth, ICMP error reports generated by
> intermediate 
> routers would be sent along the source path instead of relying on the 
> perhaps false source address.  (This might require some modifications 
> to the error reporting functionality, but I think that wouldn't be 
> that hard.)  
> 

Best Regards
 Thomas Eklund
--------------------------------------------------------------------
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: "Glenn Morrow" <[email-masked]>
Date: Thu, 12 Apr 2001 16:56:13 -0500

Thomas,

Again I wish to bring up that if a slave has been infected and a root kit
installed, any credentials on that node will likely be available to be used
by the virus; therefore, any credentials used to pass any AAA and have the
ACL filter set up will be available to the root kit.

So I still think we should mandate, at least as a BCP, topological
correctness on the source.

Does this make sense to you both?

Thanks,

Glenn

-----Original Message-----
From: Thomas Eklund [mailto:[email-masked]]
Sent: Tuesday, April 10, 2001 8:39 AM
To: Morrow, Glenn [RICH2:C330:EXCH]; 'Pekka Nikander';
[email-masked]'; [email-masked]'
Subject: RE: Source addresses, DDoS prevention and ingress filtering

Hi Pekka,

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 18 Apr 2001 14:42:17 -0500

If the standard mandates it - vendors must build it in the routing products
just as they have to support ICMP etc..

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH] 
Sent: Wednesday, April 18, 2001 2:33 PM
To: 'Edward Vielmetti'
Cc: Michael Thomas; Thomas Eklund; [email-masked]';
[email-masked]'
Subject: RE: Source addresses, DDoS prevention and ingress filtering

Definitely not for IPv4 due to its deployed base but perhaps it could be
done for IPv6 - it is an idea - why not?

-----Original Message-----
From: Edward Vielmetti [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 12:41 PM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: Michael Thomas; Thomas Eklund; [email-masked]';
[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.
> 
> 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]'
> 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.
> 
> 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]'
> 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
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 18 Apr 2001 14:49:45 -0500

If something is not configurable, it IS essentially equivalent to a fiat in
an analogous sense.

-----Original Message-----
From: Edward Vielmetti [mailto:[email-masked]]
Sent: Wednesday, April 18, 2001 12:41 PM
To: Morrow, Glenn [RICH2:C330:EXCH]
Cc: Michael Thomas; Thomas Eklund; [email-masked]';

Ed

have
mobile
correctness

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 19 Apr 2001 12:30:54 -0500

Mike,

 Usually when routing policy is set up to do assymetric routing, the special
subnet exceptions are handled as part of any filtering on the first hop -
are they not?

On your note, why would this need to be done in IPv6 if filtering is
mandated on the first hop.

--------previous excerpt ---------
Note that RPF checks aren't foolproof; asymmetric
routes can cause them to kill off traffic that
shouldn't be killed. My best guess of why RPF
checks have become popular is that they're really
trivial for routers to perform and enforce (just a
FIB lookup). The same protection could be provided
via L3+ filtering, though the configuration and
performance is more problematic (though not overly
so, IMO).

Just as a note: RPF needs to be done at the edges
of the trust boundary, not the first hop router.

---

From: Thomas Eklund <[email-masked]>
Date: Thu, 19 Apr 2001 21:22:19 +0200

Hi Mike,

--> I assume you mean the reverse path forwading check in multicasting. If
so, it is the same way as for v4, you must join a multicast group in your
access network with your local/topological correct IP adress, which in case
would be the CoA (not HA). If you would like to do it with security then you
talking about secure multicast which is very pre mature but then I assume
you would like to have done it with your HA (unless you did not use the AAA
v6 draft of course then you could have used the CoA )and tunnel he traffic
from your home subnet..:-) 

 > Either way (tunneling or subnet translation), the topological
correctness is

Agreed, but IF the enterprise or service provider would haver used something
like the AAAv6 draft then they would have known that the src address would
be the same as the link identifier....

-- Thomas

---

From: Thomas Eklund <[email-masked]>
Date: Fri, 20 Apr 2001 13:25:53 +0200

Hi Christian,
I hope you not referring to the AAAv6 ideas? Because that is  just a way to
do access control and possibly combine it with the packet filters that in
most cases already sit in the router. It tells nothing about mandating it
everywhere - this is of course up to the service provider/enterprise to use,
but in the mobile systems there is a demand for AAA and this AAA draft could
be a good start. And it does not break multihoming, mobility!

Of course you can still use end-to end IPsec if you want that and at the
same time enforce authentication and authorazation towards the AAA server
and if the authentication suceeds, and then the router could update the
packet filter with the "authenticated" host's IP address (which could be the
CoA).

-- thomas

> From: Christian Huitema [mailto:[email-masked]]
> Sent: den 20 april 2001 01:11
> To: Edward Vielmetti; Glenn Morrow
> Cc: Michael Thomas; Thomas Eklund; [email-masked];
> [email-masked]
> 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...
> 
> 
> > Sent: Wednesday, April 18, 2001 10:41 AM
> > To: Glenn Morrow
> > Cc: Michael Thomas; Thomas Eklund; 
> > > the need to do subnet translation or tunneling by either the MN or
> the
> > MR.
> > >
> > >  > router's subnet, then the MN will use this as the 
> source i.e. the
> > MN's
> > > home

---

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

No, I am not referring to AAA solutions. I am referring to server side
defenses. These defenses are effective against most DoS attacks. They
may not be effective against a complete saturation attack that floods
the server's access link, but I doubt that source address verification
would be the solution to that one; after all, activists can swamp a
phone bank today without hiding their calling numbers. Replicated server
at a number of diverse location is probably more effective than source
address verification. By the way, most "server flooding" today is caused
by "flash-crowd" phenomena with plain bona-fide clients. 

-- Christian Huitema 

> From: [email-masked] [mailto:owner-
> [email-masked]] On Behalf Of Thomas Eklund
> Sent: Friday, April 20, 2001 4:26 AM
> To: Christian Huitema; 'Edward Vielmetti'; 'Glenn Morrow'
> Cc: 'Michael Thomas'; [email-masked]'; 'ietf-
> [email-masked]'
> I hope you not referring to the AAAv6 ideas? Because that is  just a
way
> to do access control and possibly combine it with the packet filters
that
> in most cases already sit in the router. It tells nothing about
mandating
> it everywhere - this is of course up to the service
provider/enterprise to
> use, but in the mobile systems there is a demand for AAA and this AAA
> draft could be a good start. And it does not break multihoming,
mobility!
> packet filter with the "authenticated" host's IP address (which could
be
> the CoA).
> > > 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
> > > > Oh, I see what you were concerned about. It seems to me that an
MR
> > will

---

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 20 Apr 2001 14:52:21 -0500

I agree we probably shouldn't have a double standard - one for multihoming
and one for node mobility. 

On Christian's point about trusting some foreign node to do something, I
think we already trust these foreign routers to route packets to the right
point which is along the same lines of trust, IMO. I believe there is an
installed base of older IPv4-only routers out there that people still want
to use and leverage their investment as long as they can. This is a reason
to not do it in IPv4 but I don't really see why not for IPv6. I do believe
that server pods are definitely needed too.

It is no skin off my back if we don't mandate it on the first hop in IPv6. I
just thought it might make things easier for tracing down the slaves. It
seems to me that if you are going to do it - really do it and take advantage
of it. 

If topological correctness of any sort, were mandated on the first hop, it
might negate the need to do it in other parts of the network. I don't think
we are going to get people to mandate that the checks are not done on
interior hops, though.

Please understand that I'm not trying to sell some solution here or
elsewhere that depends on this functionality. I think we should consider it
to help out the DDoS problem in IPv6 if we can. So I floated the idea. That
is all.

It seems to me that there are many types of filter implementations that all
enforce some sort of topological correctness. If we ever did put it in as a
BCP or the spec itself, topological correctness at the subnet level is about
all we could say. I'm not sure if it should say subnet and interface level.
Was this your concern in reference to the server farms, Christian?

Thanks to everyone for the insightful discussion,

Glenn

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: Friday, April 20, 2001 10:53 AM
To: Christian Huitema
Cc: Edward Vielmetti; ipng; ietf-itrace
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
 > 
 > 
 > 
 > > Sent: Thursday, April 19, 2001 9:24 PM
 > > To: Christian Huitema
 > > Cc: Glenn Morrow; Michael Thomas; Thomas Eklund;
 > [email-masked];
 > > 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:
 > > 
 > > > >From a security stand point, it is very weak. You are trusting that
 > > some
 > > > 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
 > > > accept inbound packets in your domain that pretend to already come
 > from
 > > > an inside address.
 > > >
 > > > anything but symmetric. The exit path from a domain depends only on
 > the
 > > > destination address, not the source address; insisting on strict
 > control
 > > > > >  > router's subnet, then the MN will use this as the source i.e.
 > the
 > > > > MN's
 > > > > > home

---

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 20 Apr 2001 14:56:43 -0500

Christian,

The same problem is already thrown in even now as an option. This is why MIP
and other solutions have been forced to use their COA as the source. If they
don't, these routers in the middle may or may not drop their packets.
Filtering right now is kind of a pariah - you don't know if it is there or
not.

Thanks,

Glenn

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Friday, April 20, 2001 11:39 AM
To: Michael Thomas
Cc: ipng; ietf-itrace
Subject: RE: Source addresses, DDoS prevention and ingress filtering

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

> Sent: Friday, April 20, 2001 8:53 AM
> To: Christian Huitema
> Cc: Edward Vielmetti; [email-masked]; ietf-
> [email-masked]
>  > 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
>  > All in all, I wish we would not cut the node of our face. As
servers
> get
>  > > choke points on the network will *in actual practice* drop a
whole
> lot
>  > > > What happens if the "first hop" is compromised? And, by the
way,
>  > what
you
of
>  > source
>  > > > address control that has a prayer of working is local, i.e.
refuse
>  > to
come
>  > from
>  > > > an inside address.
>  > > >
>  > > > It is also very weak from a routing stand point. Internet
routing
>  > > > anything but symmetric. The exit path from a domain depends
only on
>  > > > destination address, not the source address; insisting on
strict
>  > > > > Cc: Michael Thomas; Thomas Eklund;
[email-masked]';
>  > > > > > 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
[email-masked]';
>  > > > > > Cc: Michael Thomas; Thomas Eklund;
[email-masked]';
>  > > > > >  > If the node behind the MR obtained its home address from
the

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 24 Apr 2001 07:50:18 -0700

I am well aware of the threat model. I still believe that we have to
find a solution that does not "cut our nose to cure the cold." I have
specifically discussed how the attack can be fought by other means, and
how the attacker can in fact move from "spray" to other disguises and
still continue causing the problem. We have to find a solution that does
not prohibit mobile IP or multihoming.

-- Christian Huitema 

local
logical
of
some
really
source
from
the
control
> > > Cc: Michael Thomas; Thomas Eklund; [email-masked]';
'ietf-
across
practice
MR
the