Subject: RE: [mobile-ip] Routing header Vs tunneling

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Fri, 7 Dec 2001 16:18:06 -0600

> > 2   MIPv6 Security Discussion                     75 Mins
> > 
> >     a. Securing MIPv6 Binding Updates
> > 
> >     b. Home Address Option/Routing Header vs Tunnelling
> 
> I think we should modify 'b' to say " Home Address Option
> vs Tunnelling" because Pekka has suggested a solution for
> the routing header problem in his
> draft-savola-ipv6-rh-ha-security-01.txt

Actually the updated agenda that I submitted to the IETF before the
deadline
read this item as :
......
    b. Security requirements for Home Address Option and Routing Header
......

Did not really intend to compare tunnelling schemes.

-Basavaraj

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 9 Dec 2001 00:46:10 +0100 (CET)

Glenn,

> That said - what is the use of sending the extra addresses in each packet at
> all since per-address authorization state must be kept on the tunnel
> endpoints in order to protect against the reflector attacks?

Are you suggesting sending packets with just two IP addresses and having the
endpoint replace the source IP and destination IP based on what it has in
the binding cache entry?

I think such an approach has some robustness problems.
 - What happens if the MN moves away and other MN appears and acquires the same
   CoA? If there is a stale binding cache entry  for the CoA->old HoA
   in some CN there will be TCP checksum failures should the new MN/HoA try to
   communicate with it since it will use the old CoA->HoA mapping.
 - What if a MN wants to have one session (e.g. TCP or VoIP) 
   with a CN using route optimization and another session  (e.g. DNS udp
lookup)
   not using route optimization. That CN would not be able to tell whether
   to apply the address replacement - the source address would be the CoA
   in both cases.

And I can't even imagine what the security issues would be in such a case.
So I think having all packets contain all the necessary IP addresses makes
sense.

  Erik

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 10 Dec 2001 13:14:25 -0600

Alessio,

You are correct and this is why I came to the conclusion that the
simultaneous operation of location privacy and route optimization is the
only true functional excuse in my opinion that could be used to put the
binding functions on the routers close to the CN. 

Now some people think that "location privacy" means that you have to hide
the location from "others" i.e. snoopers i.e. not the people engaged in
communications. I thought that "location privacy" that you didn't even want
the nodes involved in end to end communications to be able to find out where
the parties were unless they were authorized to do so i.e. in addition to
the snoopers. So the first paragraph is true based upon this definition of
"location privacy". I guess no one has really done an information id on
"what is location privacy vs anonymity? If you use anonymity have you
achieved location privacy etc..".

Thanks for bringing this up. BTW if the definition of location privacy is
just the snoopers then your previous SUCV/anonymity work could handle that.

Anyway thanks again for bringing up this point.

Glenn

> -----Original Message-----
> From: Casati, Alessio (Alessio) [mailto:[email-masked]]
> Sent: Monday, December 10, 2001 12:48 PM
> To: [email-masked]'
> Cc: Erik Nordmark; [email-masked]'
> Subject: RE: [mobile-ip] Routing header Vs tunneling
> 
> 
> 
> 
> *At 11:35 AM -0600 12/10/01, Glenn Morrow wrote:
> *>GM] Why would the mobile not want to use route optimization?
> *
> *For privacy reasons, the owner of the mobile device may not 
> *wish to reveal
> *it's current location in the network to its correspondent(s).
> *
> *Steve
> 
> Location privacy is not obtained simply by disabling 
> route optimization: the visited net addr (Care-of address) 
> is revealed to the CN by sending to it IPv6 packets 
> (with source address set to the CoA)... Not using the CoA as 
> source address comes with some ingress filtering problems...
> 
> 
> 
> Alessio
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 10 Dec 2001 13:16:52 -0600

Yes, you are right. Please see response to Claude.

> From: Steve Deering [mailto:[email-masked]]
> Sent: Monday, December 10, 2001 12:18 PM
> To: [email-masked]
> Cc: Erik Nordmark; [email-masked]
> At 11:35 AM -0600 12/10/01, Glenn Morrow wrote:
> >GM] Why would the mobile not want to use route optimization?
> 
> For privacy reasons, the owner of the mobile device may not 
> wish to reveal
> it's current location in the network to its correspondent(s).
> 
> Steve
> 
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 10 Dec 2001 13:20:02 -0600

Whoops,

I meant Claude Castellucio's work on SUCV/anonymity. 

> From: Morrow, Glenn [RICH2:C330:EXCH] 
> Sent: Monday, December 10, 2001 1:15 PM
> You are correct and this is why I came to the conclusion that 
> the simultaneous operation of location privacy and route 
> optimization is the only true functional excuse in my opinion 
> that could be used to put the binding functions on the 
> routers close to the CN. 
> 
> Now some people think that "location privacy" means that you 
> have to hide the location from "others" i.e. snoopers i.e. 
> not the people engaged in communications. I thought that 
> "location privacy" that you didn't even want the nodes 
> involved in end to end communications to be able to find out 
> where the parties were unless they were authorized to do so 
> i.e. in addition to the snoopers. So the first paragraph is 
> true based upon this definition of "location privacy". I 
> guess no one has really done an information id on "what is 
> location privacy vs anonymity? If you use anonymity have you 
> Thanks for bringing this up. BTW if the definition of 
> location privacy is just the snoopers then your previous 
> SUCV/anonymity work could handle that.
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 10 Dec 2001 13:20:36 -0600

Whoops,

I meant Allesio.

> Sent: Monday, December 10, 2001 1:18 PM

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 10 Dec 2001 13:30:23 -0600

I undertand this point of view as well. We'd have to turn off half of the
applications and protocols in use today on the Internet with the same
problems. Not the mention to be "fair", 60% of the existing RFCs should be
demoted back to drafts if put under the same scrutiny.  

This is somewhat of a brave new world with new threats. Two wrongs don't
make a right but believe me, I hear you on the getting picked on front.

regards,

Glenn

> From: Charlie Perkins [mailto:[email-masked]]
> Sent: Monday, December 10, 2001 12:07 PM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: [email-masked]
> Subject: Re: [mobile-ip] Routing header Vs tunneling
> 
> 
> 
> Glenn Morrow wrote:
> 
> I didn't think that this conclusion had been drawn.
> The reflector attack under discussion doesn't seem
> to be a horrible problem to me, and it's no worse than
> what can be done today wthout any Home Address
> destination option.
> 
> However, I still can agree that keeping extra state as
> you mention will enable protection against the problem
> anyway.  I just didn't think that it had been agreed as
> a mandated part of a solution.
> 
> > GM] Yes
> I don't think this is a good idea, unless there is some extra
> information in the two-address header that says it is O.K. to
> do the replacement.
> 
> Currently, it is possible for a mobile node to use both its
> home address and its care-of address for communications
> with correspondent nodes.  This might well be useful for
> two different data applications between the same two nodes.
> I think we should try to maintain the usefulness of the care-of
> address as a legitimate IPv6 address for applications that,
> for whatever reason, do not need mobility support.  Maybe
> SMS would be like that, if every "session" only lasted for
> a single packet.  But presumably "more" applications would
> use the home address in preference to the care-of address
> as the IP(v6) address identifying the application endpoint.
> 
> Regards,
> Charlie P.
> 
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 10 Dec 2001 13:36:33 -0600

True - We have the same definition of what location privacy is.

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 10 Dec 2001 14:08:18 -0600

Resending?

> Sent: Monday, December 10, 2001 11:36 AM
> To: 'Erik Nordmark'
> GM] Comments in-line below.
> 
> > From: Erik Nordmark [mailto:[email-masked]]
> > Sent: Saturday, December 08, 2001 5:46 PM
> GM] I think it is no less robust than what would have to 
> occur even if we did send the extra address - but I am 
> certainly open to an attempt to find some sort of stateless 
> argument for why the extra address needs to be there. I just 
> don't see it if the reflector attack is mandated to be prevented.
> 
> >    CoA?
> GM]The new mobile would have a new home address which could 
> be used to distinguish the two. The home address would have 
> had to be conveyed via some signaling i.e. something like a 
> binding update and the cache maintained. This signaling needs 
> to be authorized and authenticated in order to protect 
> against a mobile binding another mobile's home address to a 
> particular COA.
> 
>  If there is a stale binding cache entry  for the CoA->old HoA
> GM]If there is no cache entry that is valid the packets 
> should be dropped and perhaps an ICMP error message sent to 
> notify the sender (MN's COA) that they need to refresh. 
> 
> I don't see why a mobile would not want to use route 
> optimization with every node if it were available (ubiquitous). 
> 
> > 
> GM] As far as I can tell, the security issues are exactly the 
> same irrespective of whether the extra address is sent. The 
> statement doesn't detail any specific issue - by all means, please do.
> 
> GM] I have to say I am not that optimistic of such a thing 
> gaining wide acceptance any time soon; however, the 
> protections necessary against reflector attack with route 
> optimized MIP makes sending the extra address, useless. If 
> you protect against the reflector, then you have conveyed the 
> addresses to each side with credentials for authentication 
> and authorization and the CN is already having to check 
> against DDoS based upon some table. This information has to 
> be stored in a table unless you want to have to authenticate 
> and authorize on each bearer packet. 
> 
> GM] I think we have already seen some discussion on the IPv6 
> WG list about the cache etc.. It does seem that people are 
> beginning to see the point - but I must say this would be a 
> serious leep of faith. Just keep asking yourself what will 
> have to be done with the packet when there is no cache entry 
> - i.e. even if the home address is conveyed in the packet.
> 
> GM] Earlier I tried to make the point that if MIP is required 
> to deal with the reflector attack, then you might as well 
> require that the CN's do route optimization because the same 
> state will have to be kept on the CN - might as well go for 
> the gusto. The people making micro cameras and toasters with 
> IP stacks started freaking out on this though. They want the 
> small cheap footprint. 
> 
> GM] This frustrated me to no end and so now I think we might 
> need to start looking at having the routers close to the CN's 
> do some of these functions but gee - I can only imagine the 
> reaction I'll get from that suggestion from the end to 
> enders. This isn't exactly a new idea, though. Even the first 
> renditions of MIPv6 had such thoughts in it. We also have 
> GES, TUBA, 8+8, LAR, MBG, etc.. that explored this concept, 
> although many of these solutions had the tunneling overhead 
> as well. Putting the cache on the CN was easier from a 
> signaling semantics point of view because it basically 
> results in a point to point problem set as apposed to a 
> subnet to subnet problem set. This is why I think the 
> placement of the route optimization functions on the routers 
> close to the CN's was discounted in favor of the easier problem set.
> 
> GM] Route optimized MIPv6 is turning into a bunch of 
> catch-22's (footprint vs security). I think route 
> optimization should be ubiquitous irrespective of the choice 
> of where to put the cache entries. Moore's law should 
> eventually handle the footprint and economics of microcameras 
> and toasters etc.. Each time the requirements of nodes for 
> route optimization is relaxed the specification is 
> complicated and the code size on the mobile goes up because 
> it has to deal with backoff procedures.
> 
> GM]I hum for a MUST on the CN binding update requirement or 
> start having the WG look at mandating the cache on the 
> routers close to the CNs. I don't think the footprint and 
> cost people can start complaining about having a MUST for 
> routers. Whatever the choice I have a strong belief that 
> route optimization should be ubiquitous, deployable and 
> backed up by MUSTs in the specs.
> 
> GM]One thing is for sure, though. The layer-5 signaling-based 
> node mobility solutions gain in credibility each day the MIP 
> spec is debated over and incomplete. It is hard to tell who 
> on the receiver list is FUDing and who is not. I certainly 
> don't believe you (Erik) are one of the FUD people. 
> 
> GM]I mentioned a little timer earlier on the list related to 
> competition from these layer-5 solutions. The timer has 
> expired for some operators. BTW, last time I checked on these 
> layer-5 signaled solutions, they don't need tunnel overhead 
> either. But see - they are layer-5 signaling and it's O.K. to 
> make a "pseudo-connection" i.e. install and maintain some 
> state. It is the same thing -  these solutions use IP stack 
> mobility shims and swap the addresses at the endpoints. 
> 
> Regards,
> 
> Glenn
> 
> 
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Dec 2001 22:34:29 +0100 (CET)

> GM]The new mobile would have a new home address which could be used to
> distinguish the two.

Yes, but that home address would not be contained in the packet.
So when the CN receives a packet from a CoA how can it tell that
the CoA->HoA mapping has changed?

> The home address would have had to be conveyed via some
> signaling i.e. something like a binding update and the cache maintained.
> This signaling needs to be authorized and authenticated in order to protect
> against a mobile binding another mobile's home address to a particular COA.

Yes, but who would do this binding update when?
The old "owner" of the CoA might have just walked out of radio range.
The new "owner" of the CoA doesn't know which CNs might have a binding cache
entry.

BTW: I think it would be useful for you to work out the details perhaps 
as a short I-D.

> GM] Why would the mobile not want to use route optimization? I don't see why
> a mobile would not want to use route optimization with every node if it were
> available (ubiquitous). 

Limited resources - e.g. limited memory for the binding update list
or wanting to limit the total amount of bandwidth or CPU spent on
the binding update protocol.

> GM] As far as I can tell, the security issues are exactly the same
> irrespective of whether the extra address is sent. The statement doesn't
> detail any specific issue - by all means, please do.

I'll do that once there is a complete proposal I can read.

> GM]One thing is for sure, though. The layer-5 signaling-based node mobility
> solutions gain in credibility each day the MIP spec is debated over and
> incomplete. It is hard to tell who on the receiver list is FUDing and who is
> not. I certainly don't believe you (Erik) are one of the FUD people. 

Thanks for the confidence.
I'm am seriously concerned that we need the right security requirements
for MIPv6 to avoid creating a new tool for DDoS attacks but I do realize
that I am on a bit of thin ice since, even without MIPv6, there isn't
a chosen path or paths for tracing back DoS attacks. So there isn't
a very well known idea of what it means to not make it harder to deal with
DDoS.
 
   Erik

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Mon, 10 Dec 2001 21:17:06 -0600

> source address comes with some ingress filtering problems...

You could always reverse tunnel to the HA if privacy was a concern.
So at the cost of having packets tunnelled to you on the forward and
reverse paths, you could achieve privacy.

-Basavaraj

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Mon, 10 Dec 2001 22:15:09 -0600

Glenn Morrow wrote:

>Thanks for bringing this up. BTW if the definition of location privacy
is just the snoopers then your previous SUCV/anonymity  work could
handle that.

Well just to make it clear, location privacy is not a requirement for
Mobile IPv6 at this time. We had location privacy as a separate work
item in the MIP charter/milsetones earlier but that is a separate
problem and needs to be dealt as such. 

-Basavaraj

---

From: "Dave Thaler" <[email-masked]>
Date: Mon, 10 Dec 2001 20:15:11 -0800

Gabriel montenegro [mailto:[email-masked]]
 [snip]
> And yes, we should deprecate RH/HAO. Anything to make mobility less
> 'weird' and
> more in line with non-mobile wg's (IPv6) will save us problems down
the
> road.
> asbestos shields on,

I agree with Gabriel, and believe this could be done without slowing
down the spec (i.e., could be done faster than the security).  By
simplifying
processing (and yes I'm saying it does), I completely agree that it
solves
various problems now and probably a bunch more we don't know about yet.

I don't think it puts anything back to square one.

-Dave

---

From: "Patil Basavaraj (NET/Dallas)" <[email-masked]>
Date: Tue, 11 Dec 2001 00:33:02 -0600

Dave Thaler wrote:
>> 'weird' and more in line with non-mobile wg's (IPv6) will save us
>> problems down the road.
>> 
>> asbestos shields on,
>

Well, if you have followed the MIPv6 trail for some time now, I would
not be as optimistic with your view. The (many) security solutions are
now reaching a level of considerable maturity and I believe we can
reach consensus on solution(s) that can move the current MIPv6 spec
forward.  

>simplifying processing (and yes I'm saying it does), I completely
>agree that it solves various problems now and probably a bunch more we
>don't know about yet. 

Problems that we do not know about yet will arise irrespective of what
solution you decide to go forward with and there are no guarantees
that taking approach "b" instead of "a" will be any better in dealing
with "mirage" problems. So I would not consider it as a factor in
making decisions on what is the route going forward.

>I don't think it puts anything back to square one.

But it sure drags out the timeline for getting any IPv6 mobility
solution in the
near future.

-Basavaraj

---

From: "Casati, Alessio (Alessio)" <[email-masked]>
Date: Tue, 11 Dec 2001 12:18:09 -0000

Well just to make it clear, location privacy is not a requirement for Mobile
IPv6 at this time. We had location privacy as a separate work item in the
MIP charter/milsetones earlier but that is a separate problem and needs to
be dealt as such. 

-Basavaraj 

Location privacy is not an issue if

we use MIPv6 with Reverse tunneling and no Route optimization

(or, as per somebody's novel definition, no

Route Optimization "both ways"). Is there more work on Location privacy with
MIPv6

you may think about? Or should you mark this as "done".

Alessio

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 11 Dec 2001 10:37:30 -0600

The deal was that after the MIPv6 spec is a proposed standard, we can start
addressing the simultaneous operation of LP and RO. This agreement was made
some two years ago. We didn't think the spec would take that long. I think
this simultaneous operation is what was meant by the statement below.

-----Original Message-----
From: Casati, Alessio (Alessio) [mailto:[email-masked]]
Sent: Tuesday, December 11, 2001 6:18 AM
To: [email-masked]'
Cc: Erik Nordmark; [email-masked]
Subject: RE: [mobile-ip] Routing header Vs tunneling

-Basavaraj 

Alessio

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 11 Dec 2001 10:49:24 -0600

All we are seeing is IPv6 being reduced to IPv4 with expanded address space.
You are just seeing the RH being nuked for the fast-path. Perhaps we should
have seen it coming.

> From: Patil Basavaraj (NET/Dallas) [mailto:[email-masked]]
> Sent: Monday, December 10, 2001 9:45 PM
> To: mobile-ip
> Cc: gab
> >Agree. This might put me on Glenn Morrow's FUD list, but here's an
> >extreme position:
> >
> 
> Extreme indeed :)
> 
> >I think this is where the IESG must step in. Yes, the MIP wg can go
> continue
> >using RH/HAO, but I think it has been successfully demonstrated that
> >tunneling with the zill/deering extensions can accomplish the same
> thing.
> >It is the IESG's job to avoid proliferation of duplicate mechanisms.
> Better
> >one well-known mechanism than a slew of them. Definitely true for
> >security and firewalls point of view, so it can be couched in those
> >terms.
> 
> MIPv6 has been worked on for over five years now. The proposal to drop
> RH/HAO is equivalent to going back to square one and starting to
> redesign the IP mobility protocol. I think the IESG would be moving
> the yardstick on IP mobility a few years back if we decide to take
> this approach. If you want the perfect solution for IP mobility, then
> we may as well wait for a few more years and wish that an even better
> solution for moving packets between MNs and CNs comes up. Or we could
> take the current solution with the RH/HAO to completion and see if we
> can have a working solution today. 
> 
> If you really want to redesign IP mobility, there is nothing to stop
> you from doing so. But I do not believe it has to be at the cost of
> stopping the MIPv6 work in its tracks. I think we have spent more than
> enough time on trying to solve this problem. We have a few solutions
> that will fix the problem. Lets get this done now and then maybe go
> back to thinking better ways of doing tunnelling and mobility.
> 
> >
> >Notice that this nearly happened in IPv4 with Dave Johnson's minimal
> >encapsulation (rfc2004) but it didn't gain much ground cuz only the
> >MIP wg was pushing it. This new zill/deering option is now outside
> >the MIP wg, where it should be. MIP wg should just adopt it, help
> >spec it, push to put it on the fast-track and get it done. 
> >
> 
> And spend the next few years without a solution for IPv6 mobility? I
> would not even consider this as an option for MIP WG to consider at
> this time.
> 
> Maybe while the IESG is thinking of deprecating the RH and DO headers,
> they could consider a few others as well :( Sorry if this sounds so
> negative, but we seem to be digging a deeper hole to get ourselves
> into. 
> 
> >
> >asbestos shields on,
> >
> >-gabriel
> 
> -Basavaraj
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 11 Dec 2001 12:44:13 -0600

While this thread answered the question, out of context, of why a mobile
would not always want to use route optimization, the original context was
discussing the route optimized path between the MN and the CN and the need
or lack thereof for the extra home address in every packet - not the reverse
tunnel path between the MN and the HA. 

To avoid this out of context diversion from the original mail, I try once
again to make the point about the MN-CN route optimized path:

If the reflector attack is to be prevented then state must be installed and
maintained on the CN to insure that an MN is authorized to use the home
address for communications - even on handoff. Because this state must be
installed via signaling, in order for CN to protect against the reflector
attack the home address has to be conveyed in this signaling which installs
the authorization state; furthermore the CN must keep the knowledge of not
only the home address but also the care of address(es) that match up with a
particular home address in order to perform the authorization check on each
packet. Therefore it is useless, redundant and bandwidth inefficient to send
the home address on each subsequent packet between the MNs and the CNs (i.e.
packets that do not contain signaling which affects the mobility bindings
mapping the care of address to the home address). This is due to the fact
that the address binding knowledge had to already be conveyed and
maintained. And finally because this state has to be maintained on the CN to
protect against the reflector attack, if protection of the reflector attack
is mandated, we should realize that this is the same state that would have
to be maintained by CNs in order to achieve route optimization. 

The path between the home agent and the MN is a completely different subject
but before I go off and spend time on a draft describing the above, I would
like to float the question, "Is the requirement for all IPv6 nodes to
support the routing header functionality in question?" If this is not the
case then I suspect the draft will be a waste of time in that someone can
always claim stack size reduction i.e. I don't want to have to support more
than one redirection technology.

Thanks in advance,

Glenn

> From: Jari T. Malinen [mailto:[email-masked]]
> Sent: Monday, December 10, 2001 3:46 PM
> Michael Thomas wrote:
> > Steve Deering writes:
> >  > At 6:48 PM +0000 12/10/01, Casati, Alessio (Alessio) wrote:
> >  > You do bidirectional tunneling through the home agent 
> when you want to
> >  > keep your location hidden from your corrrespondents 
> (i.e., you disable
> >  > route optimization on both directions).  The outer 
> source address in
> >  > the tunneled packets from MH to HA is the care-of address, so it
> >  > gets through the ingress filters fine, and then gets 
> removed by the
> >  > HA as a natural side-effect of decapsulation, before the 
> packet goes
> >  > to the correspondent.
> > 
> >    Right, and I think that given the hazard for the
> >    CN with spooofed HAO, there needs to be a failsafe
> >    way for the MN to communicate with the CN if, for
> >    whatever reason, the CN will not accept the binding
> >    updated.
> 
> However, and this also applies to the early work we've done in
> mobile routers, if the scalability requirement of extending beyond
> infrastructures in authentication are taken seriously, also the leg
> from HA to CN is equally M to N tunneling: weak authentication (or 
> something) would logically be needed even with the reverse tunneling
> via HA.
> 
> >                 Mike
> 
> BR,
> 
> -Jari
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 11 Dec 2001 13:59:11 -0600

Jari,

Perhaps you are right. Your statement below assumes that at least RFP checks
are  being used on all 1st hop interfaces. Earlier on the IPv6 mail list and
the itrace maillist, it was brought up that topological checks should be
mandated on the first hop for IPv6. But an argument came up that FIB caches
may expire and so there may be no knowledge of whether a router is a first
hop or not. One could; however, detect the use of autoconfig on interfaces
and then have a pretty good idea that the router was a first hop. This
autoconfig detection could turn on topoligical correctness checks such as
RFP. It could also be a MUST that this happen. This would fill holes and
make your statement 100% true. It seems to me that this type of thing is
implementable and keeps the stateless nature of autoconfig intact.

I'm sure there are other more granular stateful things such as control
list/MAC spoofing checks that could be done as well but that wouldn't
exactly be stateless anymore nor conform to the high fidelity definition of
scalability. They still might provide for plug and play, though. This sort
of thing is a different beast, though. 

Again, your statement is true if topology checks are mandated on the 1st
hop. 

Glenn
 
> 
> There could still be differences in the seriousness of attacks.
> In your particular example, I'm not sure autoconfiguration has
> similar global problems as MIPv6 has; the autoconfiguration procedures
> are full of holes but can we launch attacks against some non-local
> parties through them in an easy way while at the same time escaping
> to be located?
> 
> Jari
> 
> 
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Thu, 13 Dec 2001 13:29:19 -0600

Thank You

> From: Pekka Savola [mailto:[email-masked]]
> Sent: Thursday, December 13, 2001 2:58 AM
> On Tue, 11 Dec 2001, Glenn Morrow wrote:
> 
> > What prevents a node from obtaining and using any number of 
> free or not free
> > (i.e. in use by another legitimate node) IP addresses such 
> that they can
> > spoof addresses albeit only on the same subnet IF INGRESS 
> FILTERING is used
> > on the first hop. Use of IPSEC is not mandated. Use of 
> INGRESS FILTERING is
> > not mandated, either. What is the interaction with control 
> lists, etc..
> > etc.. etc.. Are there any provisions for anti-mac-spoofing, 
> etc.. etc..
> > etc.. Pekka's draft which detailed most of the holes has 
> expired, perhaps he
> > is listening and will republish it. 
> 
> A new revision was issued:
> 
> http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-se
curity-01.txt

Thanks.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords