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

From: Steve Deering <[email-masked]>
Date: Fri, 4 Jun 1999 17:34:07 -0700

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.

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

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?

Steve

--------------------------------------------------------------------
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: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 06 Jun 1999 10:09:45 -0400

In message <[email-masked]>, Robert Elz writes:
>     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).

Fair enough, but...

First, of course, routers still can't verify the authenticity of the packets.
End systems can, however.  But -- in a world where one has to use cryptography 
to defend against threats, one can't (or at any rate, shouldn't) charge on the 
basis of unauthenticated data.  Thus, charging has to be based on the 
certificate id, not the source IP address as represented in the packets.  
Without AH, an attacker can, in principle, intercept packets in flight, modify 
them to have a phony source route, and reinject them into the net.  And the 
sole purpose of doing so it to run up your enemy's bill.  Such attacks are
certainly possible; they're also rather hard to do.  And it's strictly easier
to simply delete packets, which tends to annoy people more.  (One can't copy 
packets, and reinject them later; IPsec includes a sequence number that 
prevents replays.)

There's also the question of billing disputes -- can a server use cryptography 
to show that the client did send the packets, and that they didn't invent
the packets and hence the charges.  That's called non-repudiation, and it can
only be achieved with public key cryptography, which we can't afford on every
packet.

I should mention one thing -- it's not that I disagree with the goals of AH;
rather, I don't think they're achievable, and I think that the cost of AH 
is quite high.  It's difficult to implement, because it involves a layered 
module looking ahead at lower-layer headers.  Furthermore, the rules on how to 
determine what fields in what headers are mutable, and how to handle them, are 
quite complex.  The only comparable thing I can think of is the suggestion in 
RFC 791 that TCP should set the IP id field, so that a retransmitted packet
will, when fragmented in the same fashion, be usable to fill in holes in the
receipt of the original packet.  But even that is much simpler than this.

I think that part of the confusion today stems from early mutual 
misunderstanding of the security goals for IPv6.  In the IPng directorate, 
we all agreed that because of renumbering and routing headers, cryptographic 
authentication should be mandatory.  To me, as a security person who had 
written in 1989 on the dangers of source routing because of how easy it made 
address-spoofing, it meant that we could again use source routing because no 
one would do address-based authentication any more.  To others, it meant that 
the routing headers would be protected, and that we could therefore continue 
to use addresses-based mechanisms.  I don't recall any explicit discussion of 
this distinction.  And it's possible that we wouldn't have understood the 
problems as clearly then as we do today.