I don't see a problem with requiring routing header processing on all IPv6 hosts as long as the use of them is backed up by a secure means. The routing headers aren't the problem. The problem is the security semantics of their use.
> -----Original Message-----
> From: Pekka Savola [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 11, 2001 9:58 AM
> To: Erik Nordmark
> Cc: Jari T. Malinen; [EMAIL PROTECTED]
> Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt
>
>
> I'll try to discuss most points in this thread here..
>
> On Tue, 11 Dec 2001, Erik Nordmark wrote:
> > > So to get more clarity, is the localization (to the firewall) of
> > > controlling the use of routing header something that you
> find necessary?
> >
> > I honestly don't know.
> > Pekka brought up the issue - perhaps he can comment?
> >
> > The background for this was that allowing generic use of
> routing headers
> > is dangerous and is something that firewalls might block.
> > But I don't fully understand the severity of allowing
> general use of routing
> > headers - it does allow a DoS attacker to hide a bit since
> it could be
> > present at any previous hop in the routing header.
>
> This is an issue that came up after I wrote a draft on 6to4 security.
>
> It frustrated me a great deal that IPv6-in-IPv4 tunneling
> with the same
> protocol number 41 could be used for various things:
>
> 1. configured tunneling
>
> 2. automatic tunneling
> 2.1 automatic tunneling with compatible addresses
> 2.2 6to4
> 2.3 ISATAP
> (more to come?)
>
> If any two of 2.x are used in the same node, it's impossible to
> distinguish and create complete security rules for more than
> one of them
> simultaneously.. because protocol 41 has been overloaded.
>
> The rules can't really be made in the firewall (without encapsulation
> support etc.), but they can't really be made on the end-nodes
> either.
> Thus, this is even worse issue than here. With RH, we still
> have a choice
> for both.
>
> Sure, it's easy to make it work this way...
>
> I'd like to avoid this kind of overloading ("because it's
> easy to do it
> like that") if we can. I'd rather not repeat the same issues with
> automatic tunneling with routing headers in a few years.
>
> However, I don't see this "distinguishability" as a MUST as long as:
>
> 1) MIPv6 MUST NOT require all processing of routing headers
> be enabled in
> MN's
>
> 2) MIPv6 MUST require a special case for routing header
> processing that
> is sufficiently secure.
>
> 3)IPv6 SHOULD/MUST state (given 1,2) that nodes SHOULD NOT/MUST NOT
> enable routing header processing on hosts by default
>
> ( one could argue that currently, RFC2460 requires they must
> be processed
> [due to MIPv6] -- not all share my interpretation on this )
>
> That is, if we can say quickly enough "routing headers cannot
> harm your
> hosts!" they might not be taken as a security threat, and
> distinguishability would not be required.
>
>
> ...
>
> But really, IMO the tougher issue is how HAO will/should be handled.
>
> --
> 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
>
>
>
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
