Subject: Re: (IPng 7527) Re: Last Call: IPv6 Jumbograms to Proposed Standa rd

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 04 Jun 1999 22:58:27 -0400

In message <v04205109b37e1d1cfb72@[171.69.199.124]>, Steve Deering writes:
> At 6:30 PM -0400 5/13/99, Steven M. Bellovin wrote:
> >I don't know what to do about the flow-id.  RFC 2460 is explicitly vague 
> >about how flow-ids are to be used, and is silent on one crucial point -- can
> >routers change the flow-id en route?
> 
> We asked the ipsec WG to exclude the Flow Label from the AH computation,
> to leave open the possibility of routers changing it en-route.

OK -- in that case, AH can't protect it.
> 
> >                                                                 But my
> >conclusion -- that we had not established any particular benefit to AH's
> >semantics -- remains.  For IPv6 end-system options, my personal preference
> >it to put those after the ESP (with null encryption) header.  For hop-by-hop
> >options, AH can't help; again, such options are by definition of interest
> >to routers, and routers can't verify the AH checksum.
> 
> I don't think that's entirely true.  The Routing header is of interest
> to routers, but the ability for the final destination to verify the
> authenticity of the Routing header was deemed crucial.

Yes and no.  The authenticity of a route matters today only for programs
that do address-based authentication.  That's a broken concept (always has
been, in fact), and is made obsolete by IPsec.

But there's a more fundamental problem.  A signed source route is merely
proof that the route hasn't been tampered with after it left the signing
host.  It does not mean that it is valid, in the sense that it is authorized.
That is, suppose I want to spoof your source address.  Today, with IPv4, I
can use source routing in the header, thus overriding the routing system
on the return packet.  The intent of using AH here is to prevent that, by
having the source route authenticated.  But I can authenticate it, by
claiming to be me via IPsec, rather than you.  The AH check will find that
the checksum is valid, and that the source route is therefore good.

I can hear the objection now -- that the IPsec certificate should identify
the legitimate owner of that address, thus preventing the spoof.  Precisely --
but if it can do that, it doesn't need to verify the route if the concern
is address-spoofing.

There may be some desire to prevent an enemy from rerouting a packet.
Sorry; you can't do that this way.  Either the enemy can't intercept the
packet, in which case they can't touch it anyway, or they can, in which
case they can send it whereever they want.  Without security associations
with the routers, you can't control what they do.

Routes can have security significance in only three ways.  First, there's
simply service guarantees -- you want the packets to be delivered.  But
the routers can't interpret the AH header, so that doesn't work.  Second,
there's address-spoofing, a subject I hope I've disposed of above.  Third,
there's the desire for secrecy.  Apart from the obvious -- if I can insert
a fake routing header at some point, I can do my eavesdropping then, too --
the right way to achieve secrecy is by using ESP.

> The same may be
> true of yet-to-be-defined hop-by-hop options or "segment-by-segment"
> options (i.e., options in a Destination Options header that precede
> a Routing header).  Though the data fields of some options may be
> mutable en-route, others may not.  And in all cases, the Type and Length
> fields of an option are immutable and may need to be authenticated
> end-to-end (and are not necessarily derivable by knowing the SPI).

Mumble.  It's rather hard to analyze the security properties of something
that isn't invented yet; I don't think I'll try to.
> 
> And someone else may have also mentioned this: the Next Header field
> of the IPv6 header is not necessarily derivable/authenticatable just
> by knowing the SPI -- SPIs are supposed to be able to work at a number
> of granularities, including basic node-to-node, in which all traffic
> between a pair of nodes is covered by a single SPI, regardless of
> protocol/next-header type.  Or has the ipsec working group broken
> that too?

The Next Header field will be pointing to the AH or ESP header; their packet
formats in turn contain the original Next Header value.  I'm not sure what
the word "too" is supposed to imply, but your statement of the desired
granularities of the SPI was a fundamental design goal of all of IPsec.

My basic conclusion remains:  AH isn't particularly useful.  If you really
need to protect the header, use encapsulation (which you preferred in your
other message tonight in this thread....).

Ironically, there is one thing that AH is good for, Steve, but I don't
think it's a use you'd approve of.  Because a listener can tell that
AH is used, and hence can see a plaintext packet (as opposed to null ESP,
where without either context or heuristics you can't know that), it's
possible for it to peek at TCP port numbers, the sequence and ACK fields,
etc.  In other words, AH permits all the layer violations that the TF-ESP header
would permit and that you so strenuously opposed...
> Steve

Ditto...

--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Sun, 06 Jun 1999 18:25:21 +1000

Date:        Fri, 04 Jun 1999 22:58:27 -0400
    From:        "Steven M. Bellovin" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Routes can have security significance in only three ways.

Your list might be accurate for direct security significance, but I
don't think that's the end of the story.   Eg: one possible for future
use of routing headers is related to charging.   The routes that packets
use might have all kinds of implications to charging, from a service
provider charging at different rates based upon the path that was used
(charging more to clients who request an expensive high bandwidth path
perhaps).   Clearly this can't work unless the route can be authenticated
(at least that it represents what the originator wanted to be there).

kre