Subject: Re: I-D ACTION:draft-deering-ipv6-encap-addr-deletion-00.txt

From: Pekka Savola <[email-masked]>
Date: Sat, 1 Dec 2001 15:59:19 +0200 (EET)

On Wed, 21 Nov 2001 [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Redundant Address Deletion when Encapsulating IPv6 in 
>                           IPv6
> 	Author(s)	: S. Deering, B. Zill
> 	Filename	: draft-deering-ipv6-encap-addr-deletion-00.txt
> 	Pages		: 6
> 	Date		: 20-Nov-01
> 	
> In some potentially common uses of IPv6-in-IPv6 encapsulation 
> ('tunneling'), a node that is performing an encapsulation or 
> decapsulation will also be the source or destination of the packet 
> being encapsulated.  That can result in the same IPv6 address 
> appearing in both the outer (encapsulating) and inner (encapsulated) 
> IPv6 headers.  This document specifies a method for deleting such 
> redundant addresses from an inner header when performing an 
> encapsulation, and restoring those addresses when decapsulating, 
> resulting in a 16-octet (128-bit) reduction in header overhead, 
> per address deleted.

First a note about the applicability.

Saving 16 or 32 bytes in the datagram is IMO basically irrelevant.

What this introduces, though, is interesting: if this is used when
inner/outer addresses should match in some way (difficult to check except
in the decapsulating implementation, not good), one can get an assurance
that no one is forging the addresses -- they're basically immutable.

An example:

IPv6_NO_SRC  ==> dest address can be used for tunnel+spoofing
IPv6_NO_DEST ==> source  address can be used for tunnel+spoofing
IPv6_NO_ADDRS ==> neither address can be used for tunnel+spoofing

Note: IPv6_NO_ADDRS seems basically only usable if you want to:
 1) trick hop limit to make every destination appear as on-link, the 
idea of this below
 2) trick QoS related bits

I already mentioned my main point, that is, hop limit.  This issue should
at least be discussed in some form if nothing else.  It would be nice if
there was a way to tunnel packets in such a way that the number of hops
used for tunneling would be reflected in the internal datagram's hop
limit.  Usefulness?  One could not trick those numerous "hop limit must be
255 checks".

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

---

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

I know this hasn't come up yet - but isn't it easier to implement fast-path
tunneling than it is to implement fast-path tunneling with routing headers
just because of the placement of the addressing information in the PDUs.
Routing headers are fine for slow path signaling but probably not for
fast-path operations. Encapsulation can be accomplished with simple pointer
manipulation on packets. Routing headers require some block moves. Isn't
that the real reason why this ID is here? Why don't people just come out and
say it?

My2cents,

Glenn

---

From: "Glenn Morrow" <[email-masked]>
Date: Wed, 12 Dec 2001 08:59:45 -0600

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-masked]]
> Sent: Tuesday, December 11, 2001 9:58 AM
> To: Erik Nordmark
> Cc: Jari T. Malinen; [email-masked]
> 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.
> 
> --