Subject: (ngtrans) remote netaccess-threats via automatic tunneling

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Dec 2001 20:36:46 +0200 (EET)

Hello folks,

There was a draft on "local-link" security threats:

http://www.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt

Some of these may apply _remotely_ to nodes which implement automatic 
tunneling mechanisms (autotunnel, 6to4, ...), too.

Problem here is that if the automatic decapsulation is enabled, one can 
send packets like:

===
src=<pure_evil>
dst=<6to4/autotunnel router>
protocol=41

 src6=fe80::1
 dst6=ff02::1  [or link-local unicast, or something]
 hop limit=255 [<-- NOTE!]
 [payload]
===

Note! Tunneling decrements hop limit when encapsulating, so it cannot be
trusted.

Naturally, this is possible with configured tunnels too, but as there's
usually some trust between the two parties, it's not as interesting.  
With automatic tunneling and friends, there doesn't need to be.

Problem here is that it's possible to receive packets to link-local
addresses of the pseudo-interface via autotunneling which have hop limit =
255.

The latter is bad because several mechanisms including stateless address
autoconfiguration partially depend on hop limit as a form of weak
authorization.

This way, one can send e.g. valid link-local NS/NA/RA/RS packets that will
arrive on 6to4/autotunnel pseudo-interface.

Luckily enough, these boxes most probably are configured as Routers not 
Hosts; an exception could be e.g. this combined "6to4 host + router in the 
same box" scenario.

If the node doesn't act as a router, one could then inject e.g. router
advertisement messages on the pseudo-interface -- and they would be
processed -- from anywhere in the Internet.

There might be some nasties for routers too.

-- 
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

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 19 Dec 2001 14:21:54 -0500

Pekka

I don't think link-local attack can be carried out through automatic tunnels
(not to mention that they will fail the address checks).

After decapsulation, the packet is submitted for further input processing
to look at the innner header.  At this point, the source or destination
(or both) are link local and the packet must to be forwarded off the link
(the link in this case is the tunnel).  So in effect you are attacking
the decapsulator (a router in most cases).

However, if the decapsulator is a multicast router, then you could
pottentially attack other hosts on the lan, but not with the link-local
threats documented below.

-vlad

-- 
++++++++++++++++++++++++++++++++++++++++++++++++++++
Vladislav Yasevich		Tel: (603) 884-1079
Compaq Computer Corp.		Fax: (435) 514-6884
110 Spit Brook Rd ZK03-3/T07
Nashua, NH 03062

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Dec 2001 21:29:22 +0200 (EET)

> the decapsulator (a router in most cases).

Are you sure about this?

I don't think so.

Automatic tunneling is equivalent to configured tunneling.  Link-local
addresses can be used in manual tunnels.  AFAICS, automatic tunneling is
not really any different, except that source IPv4 address can be anything
at all.

---

From: Vladislav Yasevich <[email-masked]>
Date: Wed, 19 Dec 2001 15:13:47 -0500

Pekka

For autotunnel, see RFC 2893, Section 5.6.  Here is an excerpt:

>                                       Since automatic tunnels always
>    encapsulate to the destination (i.e.  the IPv4 destination will be
>    the destination) any packet received over an automatic tunnel SHOULD
>    NOT be forwarded.

Also,  addr-arch-v3 states:

>   Routers must not forward any packets with link-local source or
>   destination addresses to other links.

and

>   Routers must not forward any multicast packets beyond of the scope
>   indicated by the scop field in the destination multicast address.

-vlad

Pekka Savola wrote:
> --------------------------------------------------------------------
> 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: Pekka Savola <[email-masked]>
Date: Wed, 19 Dec 2001 22:21:33 +0200 (EET)

Vlad,

All that is true, but nowhere it is said that decapsulating the packet
from IPv4 (or IPv6) should be interpreted as "forwarding".

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 19 Dec 2001 13:37:44 -0800

> from IPv4 (or IPv6) should be interpreted as "forwarding".

The group keeps responding to you that the tunnel is an interface
separate from the physical one it is encapsulated in, but that doesn't
seem to stick. If you will accept that the tunnel is an independent
interface and treat it as such, all the rules will start to make sense,
and your continuous complaint about tunnel security will be resolved
through the existing rules. If you can show that a node which follows
the rules is insecure that would be helpful, but continuing to rehash
tunneling as a security hole is not.

Tony

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Dec 2001 23:48:04 +0200 (EET)

> tunneling as a security hole is not.

Please note that this is not an issue about forwarding packets with 
link-local addresses to local LAN or anything.  This is about an attack 
against the tunnel interface itself.

Undeniably, you can input packets with:

- link-local source (here: ff80::1)
- link-local destination (here: ff80::2)
- hop limit 255

in the tunnel interface.  They cannot be FORWARDED off the node though.

Now, if the router has 'ff80::2' configured as one of it's 
pseudo-interface addresses, that address can be reached via tunneling with 
hop limit 255 from anywhere.

See the potential problem here?

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 19 Dec 2001 14:23:10 -0800

Pekka Savola wrote:
> in the tunnel interface.

Not if the tunnel interface consistency check is applied to prevent it.
If you don't want to accpet link-local packets over the tunnel you are
not required to. Accepting packets through a filter needs to be done for
each of the interfaces. If you are willing to accept packets from any
IPv4 source, but not any IPv6 source, then you have to recheck the
packet once it is decapsulated.

> See the potential problem here?

Yes, the node is reachable using IPv4 from anywhere, and you are trying
to make believe that adding IPv6 is somehow a bigger problem. What is
the point? If packets can get there via IPv4, the fact that some of them
may be encapsulated IPv6 makes no difference. If a node has a policy
that packets over the global IPv4 interface go through some firewall
process, then the same policy MUST apply to the tunnel interface. If it
doesn't the site administrator is brain-dead and deserves what he gets.
If your complaint is that a site administrator can't apply grainular
policy to a link-local address over a tunnel, you are right and they
simply need to block all FE80 addresses on that interface.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2001 10:33:11 +0100

Tony Hain wrote:
> not required to. 

I'd say that was a wise precaution in a 6to4 decapsulator; I can't see
any legitimate reason to accept a link-local destination address from 
a 6to4 relay. (There's a legitimate use of link-local source addresses
in the 6to4 multicast case, but only for MLD reports, and I think we could
require hop limit = 1 in that case if we wanted.)

   Brian

> Accepting packets through a filter needs to be done for

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment at the IBM Zurich Laboratory, Switzerland
Board Chairman, Internet Society http://www.isoc.org

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Dec 2001 11:40:21 +0200 (EET)

First, let me point out a property of overloading protocol 41, from my 
draft:

--8<--
   There is a problem with multiple transition mechanisms if security is
   implemented.  This may vary a bit from implementation to
   implementation.

   Consider three mechanisms using automatic tunneling: 6to4, ISATAP
   [ISATAP] and Automatic Tunneling using Compatible Addresses [MECH].

   All of these use IP-IP (protocol 41) [IPIP] IPv4 encapsulation with,
   more or less, a pseudo-interface.

   When a router, which has any two of these enabled, receives an IPv4
   encapsulated IPv6 packet:                                          

        src_v4 = 10.0.0.1   
	dst_v4 = 20.20.20.20
        src = 3ffe:ffff::1
        dst = 2002:1010:1010::2

   what can it do?  How should it decide which transitionary mechanism
   this belongs to; there is no "transitionary mechanism number" in IPv6
   or IPv4 header to signify this.

   Without any kind of security checks (in any of implemented methods)
   these often just "work" as the mechanisms aren't differentiated but
   handled in "one big lump".

   Configured tunneling [MECH] does not suffer from this as it is point-
   to-point, and based on src/dst pairs of both IPv4 and IPv6 addresses
   it can be deduced which logical tunnel interface is in the question.

   Solutions for this include not using more than one automatic
   tunneling mechanisms in the same system or binding different
   mechanisms to different IPv4 addresses.
--8<--

In this case, consider a node which has configured tunnels, autotunnel and 
6to4.

If it receives a packet with:

src=1.1.1.1
dst=2.2.2.2
 src6=fe80::1
 dst6=fe80::2

it cannot know which mechanism this was intended for.

If configured tunnel was between 1.1.1.1 and 2.2.2.2, it could try to 
guess this must be meant for the configured tunnel. (I haven't looked into 
6to4 multicast yet, but this kind of link-local assumption might not 
hold).

however, if the packet is e.g.:

 src6=::1.1.1.1
 dst6=fe80::2

is it for configured, autotunnel 6to4 (if the box is a 6to4 relay) or 
what?

There are more unclear scenarios like this.

This makes security checks rather difficult to implement.

> packet once it is decapsulated.

Autotunneling has no such checks, and 6to4 just mentions this (in the 
context of source addresses).  Destination address?  By RFC3056, relays 
cannot have either or these checks.

Also see above.
 
> the point? 

IPv6 has local-scoped addresses that have a special significance.

Via mechanisms like 6to4 (depending on whether optional security
precautions are taken) one can inject IPv4 packets in the internal network 
that would not have passed the IPv4 checks.

> If packets can get there via IPv4, the fact that some of them

The site administrator is braindead because he allows people to use any
(it's all or nothing)  IPv6 tunneling mechanism?  Note that IPv4 site
administrator cannot know whether it's being used for configured,
automatic or whatever tunnels.  Do we want to make these braindead site
operators block protocol 41?

The point is, the checking is de-centralized from IPv4 firewalls to tunnel
endpoints.  If every host used 6to4 (the 6to4 host+router scenario), every
6to4 host would have to implement these checks, firewall policies etc.
This is when site operators say: "no thanks!  No ipv6 here please!".  Is 
that what we want?

> simply need to block all FE80 addresses on that interface.

Insecure by default?  Hopefully not for the joe-random-user -orieted 
methods like 6to4 or shipworm at least.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Dec 2001 10:55:24 +0100

In your previous mail you wrote:

   
   
=> IPv4-compatible IPv6 addresses are phased out, 6to4 documents
have an explicit section about needed checks against this kind of
attacks. If you don't fill the ... you are just breaking an open door (:-)!

Regards

[email-masked]

PS: I agree blind decapsulation is bad but this is not a scoop.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Dec 2001 12:41:36 +0200 (EET)

> attacks. If you don't fill the ... you are just breaking an open door (:-)!

ISATAP, perhaps (haven't really looked into it yet).

I disagree about 6to4:  I wouldn't say security considerations is an 
explicit section as such, and certainly not about _this_ kind of attacks.  
Just a rather vague notes.

Also note that autotunnel spec does not require that destination address
must be compatible address when decapsulating.  There's not all that much
about source either.

The issue is not about breaking the door but realizing someone left the 
back door open.

> PS: I agree blind decapsulation is bad but this is not a scoop.

Good we agree on blind decapsulation.  I dislike that security was not
discussed properly in the main context of the draft; more like as just an
afterthough "for you security geeks, here are a few possible problems.."

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Dec 2001 12:00:32 +0100

Incoming 6to4 traffic to a 6to4 site is recognized by the
fact that the destination IPv6 address is a 2002: address.
(The source may be anything if the traffic is from a relay.)

As we've always said, 6to4 relays need to know who their
cients are. This is the RFC 3056 model. 

I suspect that in the end, we will build lists of "trusted"
6to4 relays. It might be like my personal firewall, which
asks me whether to admit packets when it first sees a new
port being probed:

  Incoming IPv6 traffic from router.hacker.net; OK?

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 20 Dec 2001 13:45:07 +0200 (EET)

> (The source may be anything if the traffic is from a relay.)

Note: for relays, this is not enough identification.  And this is a 
problem when boxes implement e.g. both 6to4 and autotunneling.

Rules would be so much simpler if one could have an easy "relay" on/off
toggle.  I'm not sure if anyone has implemented 6to4 this way?  I've seen
two and both seem to apply the principle of "least security" that is, open
to all because relays require it.

Also note that decapsulation rules in RFC3056 5.3 do not require that the
destination address is 2002. (Of course, the packet must be sent
"manually" if it isn't, but encapsulation is not the point).

So, it would be "legal" to send a packet like:

src=1.1.1.1
dst=2.2.2.2
 src6=2002:0101:0101::
 dst6=<whatever>

>   Incoming IPv6 traffic from router.hacker.net; OK?

That is an improvement, but it has to contain *all* relays in the world.  
I don't think that kind of solution is ever going to scale.  

Alternatively, if we could advertise more specifics than 2002::/16 we
could control which relay is to be trusted and used.  But this has its own
problems..

Alternatively, we could trust the anycast address 192.88.99.1.  Whoever 
can spoof that, could do anything.

Currently, our relay is using only the anycast address, but not for 
security reasons.

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Dec 2001 16:54:50 +0100

=> be serious, autotunnels are phased out, configured tunnels and 6to4
are mutually exclusive...

---

From: Ole Troan <[email-masked]>
Date: Thu, 20 Dec 2001 16:12:54 +0000

> are mutually exclusive...

mutually exclusive? I don't think so.

as was pointed out earlier as long as one uses a different IPv4 source
address for the different point to multi-point tunnelling mechanisms
there is no problem demultiplexing the packet to the correct tunnel
interface.

/ot

---

From: Francis Dupont <[email-masked]>
Date: Thu, 20 Dec 2001 17:13:54 +0100

=> no, we come back to the last week discussion...

=> autotunnel ist phased out. Security issues are one of the reasons
but in fact 6to4 is better (including from the security point of view).

   
=> let someelse answer...

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 20 Dec 2001 10:23:09 -0800

> require hop limit = 1 in that case if we wanted.)

I did present a case in my 6to4-scale draft, but that was specific to
ICMP between a 6to4-router and 6to4-relay for RS/RA use in NUD. To
address the spoofing issue I used a random value generated by the
6to4-router to be echoed by the relay. In any case there was not much
interest in that path, so as you say there are no current reasons beyond
multicast.

Tony

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 20 Dec 2001 10:42:49 -0800

Pekka,

Let me respond to the below from the perspective of ISATAP and 6to4
tunnel mechanisms at work in the same machine. For example, let us
suppose that a 6to4 router is also acting as an ISATAP router. In this
case, there will be (at least) *two* distinct tunnel pseudo-interfaces;
one for 6to4 and one for ISATAP. These pseudo-interfaces *may* bind to
the same physical link, but they need not do so and (in practice) often
will not.

In any case, however, the tunnel pseudo-interfaces are uniquely identified
by the IPv4 address assigned to each. As long as different IPv4 addresses
are assigned to the different tunnel pseudo-interfaces (a configuration
requirement for FreeBSD and Linux, at least), there will never be a case
of ambiguity such as the one you describe below. Note that if a single
physical link were used, this would mean assigning two or more IPv4
addresses to the same link. But, all OS's I work with support this.

Am I belaboring an already obvious point?

Fred
[email-masked]

---

From: Vladislav Yasevich <[email-masked]>
Date: Thu, 20 Dec 2001 16:17:11 -0500

Fred

I believe Pekka is comming from the linux implementation point of view
which has only one pseudo-interface (sit0) to act as tunnel endpoint
(at least that's what I see on my linux box).  This is really the problem
that leads to not being able to distinguish between tunneling mechanisms.

-vlad

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 20 Dec 2001 13:39:01 -0800

Vladislav,

If you use the 'iproute2' package under recent releases of the Linux
kernel (e.g. recent releases of 2.4.*), you will see that the command:

  # ip tunnel add

allows you to add as many auto-tunnel pseudo interfaces as you'd like.
For example, try:

  # ip add tun1 mode sit remote R1 local L1
  # ip add tun2 mode sit remote R2 local L2
  ...
  # ip add tunn mode sit remote Rn local Ln

and you should see n-many 'tun' pseudo-interfaces pop up when you
issue the command: 'ifconfig -a'. (Above, Ri and Li represent the
remote and local IPv4 addresses assigned to pseudo-interfaces 'tuni'
for 1 <= i <= n). The 'sit0' is simply there as a "base" upon which
multiple pseudo-interfaces may be layered.

If you get the 'iproute2' package from:

  http://v6web.litech.org/isatap/

you will see the following when you issue the command: 'ip tunnel help':

> Usage: ip tunnel { add | change | del | show } [ NAME ]
>           [ mode { ipip | gre | sit | isatap } ]
>           [ remote ADDR ] [ local ADDR ] [ v4any ADDR ]

So, to create an ISATAP tunnel, simply use the "mode isatap" directive.

Fred
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Dec 2001 00:36:19 +0200 (EET)

This is getting too implementation-specific, so I guess we had better kill 
this thread, at least from here...

>   # ip add tunn mode sit remote Rn local Ln

Autotunnel/6to4 interfaces by definition don't have specific destinations;  
this is useful for configured tunnels, though.  (This is how configured
tunnels are created e.g. with probably most distributions).

> multiple pseudo-interfaces may be layered.

Multiple pseudo-interfaces should be possible, yes.  But being built this
way, the kernel performing security checks cannot know which interface is
which.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Dec 2001 00:39:46 +0200 (EET)

Getting kinda off-topic for this scope..

> addresses to the same link. But, all OS's I work with support this.

How will the kernel police that local IPv4 address is different for each?

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Dec 2001 00:43:31 +0200 (EET)

> but in fact 6to4 is better (including from the security point of view).

There is no "official" say about the former.  Not anything as far as I can
tell.

Additionally, there are probably many people who rather write 'ping6
::123.123.123.123' than calculate in the head 123=0x7b (or all four in a
more complex scenario) and type 'ping6 2002:7b7b:7b7b::1'.

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 20 Dec 2001 15:11:42 -0800

There has clearly been some confusion caused by sloppy instructions
in my previous message; sorry about that. To close this out:

 1) multiple tunnel pseudo=interfaces are supported under Linux
 2) the correct syntax for configuring an ISATAP auto-tunnel is:

   # ip tunnel add isatap0 mode isatap local V4ADDR

where 'V4ADDR' is an IPv4 address assigned to a physical link. Please
see:

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 20 Dec 2001 15:13:15 -0800

> where 'V4ADDR' is an IPv4 address assigned to a physical link. Please

Please see:

for more details.

Fred
[email-masked]

---

From: "Fred L. Templin" <[email-masked]>
Date: Thu, 20 Dec 2001 15:18:35 -0800

Pekka,

> How will the kernel police that local IPv4 address is different for each?

Since this is getting off topic (as you say), I will refer you simply to
the Linux 'sit.c' device driver found in:

  /usr/src/linux/net/ipv6/sit.c

Preferrably, look at the version in the latest USAGI CVS tree at:

  http://www.linux-ipv6.org

The answer to your question is that the kernel *does* enforce the local
IPv4 address as different for each tunnel pseudo-interface as can easily
be seen from reading the code.

Fred
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2001 11:56:50 +0100

> this thread, at least from here...

In fact, it would be a fundamental error to make protocol choices on the
basis of perceived implementation glitches in today's popular operating
systems. If we do the "right thing", one of these days the o/s will
catch up.

That doesn't deny the value of informational documents about today's
implementation issues, especially security threats.

   Brian

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 13:46:28 +0100

=> if you have a configured tunnel you can use native addresses so
you don't need a 6to4 router. They are mutually exclusive in practice
(note that 6to4 relays are a different problem, in fact the box where
is the local 6to4 relay has a configured tunnel too but with a lot of
address checks (FreeBSD) and extra filtering).

=> a configured tunnel is identified by its IPv4 address pair so
conflicts can happen only if both ends are involved in a set of
mechanisms with more than one element, i.e. in practice the only
special case is a configured tunnel between two 6to4 relays...
 Of course as this is a weak authentication based on addresses
one should use usual protections like RPF based ingress filtering.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Dec 2001 15:23:39 +0200 (EET)

> systems. If we do the "right thing", one of these days the o/s will

My gripe with 6to4 is that it doesn't discuss the security issues
properly.  Everything about security is basically written (rather
concisely), in security considerations, like sugar coating on a cake.  

IMO, this is the wrong approach.  Security precautions should be discussed
and handled all the way through the specification (as with Shipworm), and
in security considerations, a summary and remainder threats discussed.  
Remainder threats are not covered there.

A few points from along the course of this thread:

- 6to4 does not require the checks and the threats are partially 
downplayed
- automatic tunneling does not discuss the checks even that much
- issues with multiple use of configured/autotunnel/6to4/... on the same 
box is not covered AFAIK anywhere
- should autotunnel be deprecated in a more official fashion?

> implementation issues, especially security threats.

This is what my draft was/is partially meant to be; from my perspective (I
looked at Linux and KAME) it appeared that the checks had been implemented
only partially or not at all. Perhaps partly because they may not have
been understood to be important, or were difficult to implement because of 
the problem with multiple mechanisms.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Dec 2001 15:27:22 +0200 (EET)

> you don't need a 6to4 router. They are mutually exclusive in practice

site-locals (or even 6to4 /64's, for site-internal tunneling) could used
for configured tunneling in the presence of 6to4 :-).

Relays are a difficult issue which IMO much less understandable.

The issue is more about mutual exclusivity of autotunnel and 6to4, on 
which I don't agree with your view..

---

From: Francis Dupont <[email-masked]>
Date: Fri, 21 Dec 2001 17:29:51 +0100

> but in fact 6to4 is better (including from the security point of view).
   
   There is no "official" say about the former.

=> fine, is it the time to fix that?

Regards

PS: please remove the IPng mailing-list from the cc field.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Dec 2001 16:05:01 +0100

> Relays are a difficult issue which IMO much less understandable.

Yes, 6to4 relays are subversive; as I've said, I'm sure we'll end up with
ACLs for relays or at least blacklisted relays.
> which I don't agree with your view..

But at least one of the addresses is 0/96 in the case of an automatic tunnel packet
and 2002/16 in the case of a 6to4 packet. Doesn't seem to hard to distinguish.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Dec 2001 16:11:25 +0100

> concisely), in security considerations, like sugar coating on a cake.

Actually I think the decapsulator pseudocode indicates where checks
should be made, and as far as I know that is the only place where
security would come in. Yes, the description is in boundary condition
terms, which the WG thought was necessary and sufficient at the time.
> Remainder threats are not covered there.

Are you aware of any except spoofing?
> - 6to4 does not require the checks and the threats are partially

It's very hard to attach MUST to checks which are implementation
and deployment specific. 

> box is not covered AFAIK anywhere

Quite true.

> - should autotunnel be deprecated in a more official fashion?

Probably. That means removing it from the address architecture and from
RFC 2893.

> the problem with multiple mechanisms.

I think your draft is useful.

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Thu, 27 Dec 2001 13:01:33 +0200 (EET)

> Are you aware of any except spoofing?

Aware of what, exactly?  Remainder threats? From the top of my head,

if proper checks are not implemented:
 - being able to send hlim=255 link/site locals to the pseudointerface
 - numerous other more general spoofing attacks

if checks are implemented:
 - relays used for reflection (to 2002:[target ipv4], possibly 
broad/multicast)
 - relays being used without authorization (theft of service and how to 
avoid it) [BGP advertisement restrictions aren't enough]
 - more or less authorized relay sending e.g. spoofed 2002:: packets

As can be seen and has been seen, relays are the toughie here..

> Probably. That means removing it from the address architecture and from

Addrarch revision is underway (close to complete I fear), so this might be
the chance to do one of these (next one would possibly be in 2-3 years).  

I commented on the fact earlier too, because I didn't see all that much
point in describing just one special tunneling technique in addrarch.

If curious, the message was:

Date: Sun, 26 Aug 2001 00:20:38 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: Bob Hinden <[email-masked]>
cc:  <[email-masked]>