Subject: [Isis-wg] Re: Deprecation of AH header from the IPSEC tool kit

From: Paul Koning <[email-masked]>
Date: Wed, 14 Jun 2000 13:25:08 -0400 (EDT)

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:

 Michael> Paul Koning writes: What keeps nagging at me is the overhead
 Michael> of both AH and ESP, not to mention the added complexity.
 Michael> This might be water well under the bridge, but has the
 Michael> thought of having a mode to ESP which protects the outer
 Michael> headers?
 >>  That's no help, because that is exactly the difference that makes
 >> AH so much harder than ESP.  (Well, there's details like having
 >> the MAC in the header rather than the trailer.  Then again, ESP
 >> puts the NextHeader value in the wrong place, so they're even...)
 >> 
 >> The reason I like ESP authentication is precisely the fact that it
 >> doesn't contain all the hair needed to protect a subset of IP
 >> header fields.

 Michael> Maybe you're misunderstanding me: if ESP had a bit which
 Michael> said "I'm protecting the outside headers too", it could be
 Michael> either signaled or potentially even done on an as-needed
 Michael> basis by the IPsec stack for IP headers which would
 Michael> otherwise require AH. I'm all for not protecting things that
 Michael> don't need protection otherwise.

I think I understood.

The issue is that the bit you're describing is actually the only
essential difference between AH and ESP.  In other words, you can
think of it as the "do AH" bit.

You can't just "protect the outside headers too".  You have to be
selective about it, protecting only immutable ones, skipping fields
and headers that change in transit, mumble mumble mumble.  That's the
"hair" of AH I'm referring to.  It doesn't matter what you call it or
how you encode it.  The hypothetical "ESP with the bit" you describe
has to do the same thing so it has to contain the same amount of hair.

    paul

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Paul Koning <[email-masked]>
Date: Wed, 14 Jun 2000 14:19:19 -0400 (EDT)

>>>>> "Ben" == Ben McCann <[email-masked]> writes:

 Ben> Aren't your goals met by using ESP _tunnel_ mode? Just tunnel
 Ben> the OSPF, RIP, etc, packet from one box to the other. The
 Ben> tunneled packet has an inner IP header is completely secured by
 Ben> ESP. This is the header seen by OSPF, RIP, etc, once ESP
 Ben> completes the authentication of the packet.

That certainly does the job.  The trouble appears if someone wants to
use transport mode (perhaps to save a few bytes) and then decides that
for some reason there are IP headers worthy of protection.  That's
where the messy hybrid (AH) appears.

    paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 14 Jun 2000 09:33:05 -0400 (EDT)

>>>>> "Waters," == Waters, Stephen <[email-masked]> writes:

 Waters,> There has been some discussion recently on the possible
 Waters,> deprecation of the Authentication Header defined for
 Waters,> 'whole-packet' authentication.

 Waters,> I 'think' the decision was to leave it alone, and allow AH
 Waters,> to wait for its day.

 >> From reading the various, associated methods of securing ISIS,
 >> OSPF and
 Waters,> RIPV2 messages, it seems to me that AH is perfect for the
 Waters,> protection of these protocols.

 Waters,> The current HMAC-MD5 options have the following exposures
 Waters,> that are solved with AH:

 Waters,> 1) no source address authentication (IP header
 Waters,> authentication in general) 2) poor/no replay protection 3)
 Waters,> manual keys - which restricts key length and complexity to
 Waters,> human-manageable keys, and makes for difficult key change
 Waters,> procedures.

 Waters,> IPSEC+AH would seem to be a good choice for all control
 Waters,> traffic exchange between routers. If this exchange is
 Waters,> confidential, the ESP could be used as well.

Yes, but if it's not confidential (which is the likely case) then ESP
in authentication only mode will serve just as well.

It's never been the point of any of this discussion to deprecate the
notion that authentication is useful -- the issue is whether it makes
sense to retain AH when ESP does the job with significantly less
hassle.

   paul

---

From: Paul Koning <[email-masked]>
Date: Wed, 14 Jun 2000 13:03:43 -0400 (EDT)

Michael> Paul Koning writes:
 >> It's never been the point of any of this discussion to deprecate
 >> the notion that authentication is useful -- the issue is whether
 >> it makes sense to retain AH when ESP does the job with
 >> significantly less hassle.

 Michael> What keeps nagging at me is the overhead of both AH and ESP,
 Michael> not to mention the added complexity.

That's no help, because that is exactly the difference that makes AH
so much harder than ESP.  (Well, there's details like having the MAC
in the header rather than the trailer.  Then again, ESP puts the
NextHeader value in the wrong place, so they're even...)

The reason I like ESP authentication is precisely the fact that it
doesn't contain all the hair needed to protect a subset of IP header
fields.

	paul

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Jun 2000 08:29:41 -0700 (PDT)

> sense to retain AH when ESP does the job with significantly less

   What keeps nagging at me is the overhead of both AH
   and ESP, not to mention the added complexity.

   This might be water well under the bridge, but has
   the thought of having a mode to ESP which protects the 
   outer headers? I know that's contrary to the 
   "encapsulating" part, but if we want to converge
   on one crypto header, it seems to me that placing
   an artificial restriction that outside headers can
   never be protected is pretty arbitrary and wrongheaded
   (even though I'm persuaded by Steve Bellovin's arguments
   about v4 headers).

	    Mike

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jun 2000 16:22:37 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:
    Michael> Maybe you're misunderstanding me: if ESP had a bit which said
    Michael> "I'm protecting the outside headers too", it could be either
    Michael> signaled or potentially even done on an as-needed basis by the
    Michael> IPsec stack for IP headers which would otherwise require AH. I'm
    Michael> all for not protecting things that don't need protection
    Michael> otherwise.

  The point that Steve Bellovin keeps making, and which he has written about,
is that AH does not provide much more in the way of authentication that
ESP does not (at least for IPv4). The outer headers are all either
irrelevant, or can be derived from the SPD, so you don't have to trust them.

  I believe that there are other things that AH provides (like the 
guarantee that the contents are not encrypted and therefore can be audited),
and things that will be defined in IPv6-extension land that will make AH
a useful thing to keep in the spec, just not MUST it.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
	mailto:[email-masked]	mailto:[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 14 Jun 2000 15:02:50 -0400

>> sense to retain AH when ESP does the job with significantly less

    Michael> What keeps nagging at me is the overhead of both AH and ESP, not
    Michael> to mention the added complexity.

  If two routers need privacy and authenticity, they can use end-to-end ESP,
as they can get strong origin authentication by virtue of the integrity
check succeeding in the ESP. Don't trust the source IP, rather take the
appropriate source IP from the SA to look up the appropriate PCB for the
TCP/UDP session you are protecting.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Jun 2000 10:20:06 -0700 (PDT)

> doesn't contain all the hair needed to protect a subset of IP header

   Maybe you're misunderstanding me: if ESP had a
   bit which said "I'm protecting the outside
   headers too", it could be either signaled or
   potentially even done on an as-needed basis
   by the IPsec stack for IP headers which would
   otherwise require AH. I'm all for not
   protecting things that don't need protection
   otherwise.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Jun 2000 11:54:05 -0700 (PDT)

Ben McCann writes:
 > Aren't your goals met by using ESP _tunnel_ mode? Just tunnel the OSPF,
 > RIP, etc, packet from one box to the other. The tunneled packet has an
 > inner IP header is completely secured by ESP. This is the header seen
 > by OSPF, RIP, etc, once ESP completes the authentication of the packet.
 > 

   See my previous post. Throwing bytes at the problem
   is certainly one way to solve it, but it may not
   be practical in many, many cases.

		Mike

---

From: "Waters, Stephen" <[email-masked]>
Date: Wed, 14 Jun 2000 10:38:55 +0100

There has been some discussion recently on the possible deprecation of the
Authentication Header defined for 'whole-packet' authentication.  

I 'think' the decision was to leave it alone, and allow AH to wait for its
day.

From reading the various, associated methods of securing ISIS, OSPF and
RIPV2 messages, it seems to me that AH is perfect for the protection of
these protocols.

The current HMAC-MD5 options have the following exposures that are solved
with AH:

1) no source address authentication (IP header authentication in general)
2) poor/no replay protection
3) manual keys - which restricts key length and complexity to
human-manageable keys, and makes for difficult key change procedures.

IPSEC+AH would seem to be a good choice for all control traffic exchange
between routers. If this exchange is confidential, the ESP could be used as
well.

Regards, Steve.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 14 Jun 2000 11:48:19 -0700 (PDT)

> has to do the same thing so it has to contain the same amount of hair.

   Sure. Doing AH-like functionality is a pain; if you
   have to do it, you have to do it -- that's just a
   given. What I don't like is having a completely 
   separate header with its associated complexity and
   (especially) overhead. Right now though, if I had 
   a flow which for some reason need privacy and outer
   header protection (ie, AH functionality), you'd have
   to put on an AH and ESP header. This means that the
   SPI and the Sequence are completely redundant, as 
   well as having to burn another longword for the 
   redundant header, thus I'm having to add yet another
   12 bytes per packet. If we're talking about something
   like RTP audio, that's probably significant. 

   Then of course there's the issue of, say, CRTP. I don't think
   that a profile for crypto for CRTP has been done to
   compress the predictable parts of the crypto headers,
   (ie, SPI, SEQ, next header), but having to contend 
   with *both* AH and ESP would make crypto-aware CRTP
   an even uglier proposition. The same, incidentally,
   goes for normal header compression, and the coming
   IP enabled cellular stuff is going to absolutely 
   demand both compression as well as security. 

   Whether it is wise to open up this debate yet again
   is questionable, but life is only going to get more
   complicated if AH stays around. Pick your poison.

		  Mike

---

From: Ben McCann <[email-masked]>
Date: Wed, 14 Jun 2000 14:07:16 -0400

-Ben McCann

-- 
Ben McCann                              Indus River Networks
                                        31 Nagog Park
                                        Acton, MA, 01720
email: [email-masked]           web: www.indusriver.com 
phone: (978) 266-8140                   fax: (978) 266-8111