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

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 13 May 1999 18:30:36 -0400

In message <v04204f08b360b171f9b2@[171.68.181.149]>, Steve Deering writes:

> That's clearly false for the Payload Length field in the IPv6 header,
> and of unknown truth value for yet-to-be-defined Hop-by-Hop options.
> 
> I've never seen Steve Bellovin's analysis that you refer to above.
> Is there an emailmessage or a paper containing that analysis which
> could be forwarded to this list?

Here's the analysis I sent in July '95, from (as I recall) the terminal
room in Stockholm.  It concerns IPv4, not IPv6, but I see little that
would change, with the possible exception of the flow id.  You're right
that the payload length field is important; however, the actual length
of the payload is included in the MD5 or SHA-1 pass over the payload,
so tampering would be detected.

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?  There are architectures that make
that a very useful ability.  In any event, it doesn't matter much for
purposes of AH -- flow-ids are mostly useful to routers, not end systems,
and routers can't verify the AH field.  Besides, AH can only cover what
the host *says* it's using, not what it's entitled to use.  That doesn't
matter much for flow-ids; it matters a great deal for IP addresses, which
are the main things people want assurance about.  If my IP address matters,
it has to be in my certificate (and that's one of the choices in the ipsec
architecture); if it doesn't, why check it?

Bear in mind that this analysis was written before RFCs 1825-1829 were
published; the language about option processing was cleaned up.  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.

---
With one possible exception I haven't analyzed -- the multicast case --
it does not make sense to include the IP header in the AH checksum.
In fact, as currently specified it cannot be implemented by a stack
that conforms to other standards, notably RFC 1122.

Here's a field-by-field analysis of the IPv4 header:

u_char  ip_hl:4,                /* header length */
                Options only -- see below
        ip_v:4;                 /* version */
                Constant, and hence meaningless
u_char  ip_tos;                 /* type of service */
                Of interest to routers, which don't check AH
short   ip_len;                 /* total length */
                Included in the MD5 calculation anyway
u_short ip_id;                  /* identification */
                meaningless after reassembly
short   ip_off;                 /* fragment offset field */
                changes en route
u_char  ip_ttl;                 /* time to live */
                changes en route
u_char  ip_p;                   /* protocol */
                Probably doesn't need checking; can be bound to SPI
                if needed.
u_short ip_sum;                 /* checksum */
                No point to verifying
struct  in_addr ip_src
                Bound to SPI
        ip_dst;                 /* source and dest address */
                Bound to SPI

As for options, except for security label the remaining options
are either changeable en route, and hence exempt, or of interest
to routers, or both.  Furthermore, the AH spec says that we can't
enumerate the v4 options, and hence whether or not they should
be included or not -- but RFC1122 says that unknown IP options
MUST be silently ignored.  So an implementation can receive an
option that it doesn't recognize, doesn't know if it changes
en route, must be ignored anyway -- but may or may not be included
in the AH calculation, and the receiver doesn't know.

The security label is one that might require integrity.  But I'd
expect it to be bound to the SPI, since sensitivy level is one
of the factors that has to be used in negotiating algorithms.  If
it's not -- well, arguably authenticated explicit security labels
could be used on a multilevel cable, but if you have folks tinkering
with security levels on such a cable they could inject phony labels
or packets; I'd expect that encryption would -- and should -- be
used instead.

In short -- with the exception of multicast, which as I said I haven't
analyzed yet -- David Wagner is right; there seems to be no reason to
include the IP header in the AH calculation.  And it adds a lot of
implementation complexity.  At most, we should emulate the approach
taken for the TCP and UDP pseudo-header in their checksum calculations.
But that seems to be a waste of effort.  The length is already in the
MD5 checksum, the source and destination addresses are bound to the
SPI, and it is generally agreed that the need for verifying the protocol
field never materialized.

--------------------------------------------------------------------
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: Craig Metz <[email-masked]>
Date: Thu, 13 May 1999 19:10:52 -0400

In message <[email-masked]>, you write:
>and routers can't verify the AH field.

  Um, actually, there are good reasons why routers might want to (they would,
of course, have a SA for this purpose). This is one of the reasons why
multiple AHs can sometimes be useful.

>                Probably doesn't need checking; can be bound to SPI

  IMO, ICMP about a flow should use the same SA as the bulk of the flow, which
wouldn't be possible if we bound this to the SA.

>to routers, or both.

  The easy solution is to just not use options (or IPv6 options bag headers and
routing headers). In many parts of the 'net, you already can't get very far if
there are options in your packets.

  If you simply don't use options, then I agree with you that we can get away
with basically only doing the transport header/encapsulating header and the
payload beyond.

>The security label is one that might require integrity.

  It requires integrity and might require intermediate checking.

									-Craig

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 May 1999 10:40:35 +0100

Craig Metz wrote:
...
> there are options in your packets.

That's really not acceptable. It's a bug that we can't implement
new IPv4 options in practice, and this is a bug we must not
propagate in IPv6.

   Brian
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter (IAB Chair)
Program Director, Internet Standards & Technology, IBM Internet Div
As of May 24, 1999: on assignment for IBM at http://www.iCAIR.org 
Non-IBM email: [email-masked]
--------------------------------------------------------------------
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: "Matt Crawford" <[email-masked]>
Date: Fri, 14 May 1999 08:54:30 -0500

> short   ip_off;                 /* fragment offset field */

When fragmentation is done en route, the bad guy can insert bogus
fragments, making correct reassembly an exponential problem.  Even
when fragmentation is done solely by the source, the rules for AH
(reassembly before ICV check) make the same attack possible.

---

From: [email-masked]
Date: Fri, 14 May 1999 23:55:41 +0900

>(reassembly before ICV check) make the same attack possible.

	But you'll be able to detect the fragment insertion by ICV,
	don't you?

itojun

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 14 May 1999 10:53:07 -0500

> 	But you'll be able to detect the fragment insertion by ICV,

You'll detect that something is wrong.  If you want to reassemble a
good packet, you'll have to try every possible combination of
frgaments until you find one that passes the check.

			Matt