RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard

"Patel, Baiju V" <> Fri, 27 March 1998 16:39 UTC

Received: (from majordom@localhost) by (8.8.2/8.8.2) id LAA10040 for ipsec-outgoing; Fri, 27 Mar 1998 11:39:35 -0500 (EST)
Message-ID: <A1B6CB375930D11188D100A0C95A36BD0114785B@FMSMSX31>
From: "Patel, Baiju V" <>
To: 'Peter Ford' <>, "''" <>
Cc: "''" <>
Subject: RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
Date: Fri, 27 Mar 1998 08:41:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk

I fully agree with Peter's first comment. It is a problem to 
implement AH in hardware on the fly, because
you have to hold the entire packet till Integrity
check is completed (the signature is placed at the
beginning of the packet).
The same functionality as AH can be achieved by
implementing ESP in tunnel mode. In most cases,
ESP with NULL encryption will suffice anyway.

Therefore, either AH should be removed entirely,
or at least it should not be considered mandatory
to implement.

The following paragraph is from a mail to this
working group by Steve Bellovin.
--- Steve's paragraph ---
You can use AH+ESP to protect the IP header, or you could use ESP in
tunnel mode, even between two end hosts.  While some of us do indeed
feel that we should not have two such similar options, there was
no consensus on eliminating AH+ESP, or on eliminating AH altogether,
in favor of ESP with a null encryption transform.
--- End of quote ---


-----Original Message-----
From: []On Behalf Of
Peter Ford
Sent: Thursday, March 26, 1998 9:04 PM
To: ''
Subject: RE: Last Call: Security Architecture for the Internet Protocol
to Proposed Standard

The IPSEC group should be commended for getting this large body of work to
this phase.

Onto comments.   Disclaimers apply.  My list is ordered.  This number 1
topic is an old one, but given that we are really at the beginning of an era
of standardized IPSEC it seems worth discussing  and understanding what we
are all commiting to.

comment 1)  Many people who are in the middle of implementing IPSEC AH are
discovering the ugliness of this thing. Many are wondering in the privacy of
their own development shops why we don't simply eliminate this AH thing and
build the equivalent functionality into a set of ESP transforms.   This
would result in a cleaner set of implementations and probably smaller,
cheaper, better silicon and code.  In my own casual survey I have yet to run
into anyone who feels strongly about keeping and/or using AH.

Our experience at Microsoft working with hardware folks (chip, cards,
motherboards, smartcards, etc.)  who are working on  IPSEC is that they
would like to worry about one form of encapsulation, and they would like to
put the AH ICV at the end of the packet ala IPSEC ESP. 

COMMENT 2)  It is not clear if one would call it a protocol bug or not, but
as currently spec'd it is possible for two peers to get into the following

a) SAs established based on data flow triggering from A to B, A is the
initiator (e.g. policy on A: do IPSEC for traffic to peer B)
b) A crashes
c) B holds an SA and believes the other side (A)  is still able to undo
IPSEC traffic on the SA that was wiped out on the reboot of A.  All IPSEC'd
traffic from B to A is unusable and nothing drives the establishment of new
SAs btw A and B since A has no traffic destined for B and B already has what
it thinks are valid SAs to A.

there are several proposals for peer recovery floating around, but without
it the spec seems incomplete.

comment 3)  Calling something "The Internet Key Exchange" seems a little out
of place given the wild mileau of Key exchanges floating around in IETF
working groups, let alone on the Internet at large.

If AH moves to PS, customers will expect it to be part of ALL
implementations.  This is the time to simplify IPSEC.

cheers, peter

> -----Original Message-----
> From:	The IESG []
> Sent:	Friday, March 20, 1998 12:08 PM
> Cc:
> Subject:	Last Call: Security Architecture for the Internet Protocol
> to Proposed Standard
> The IESG has received a request from the IP Security Protocol Working
> Group to consider publication of the following Internet-Drafts as
> Proposed Standards:
>  o Security Architecture for the Internet Protocol 
> 	<draft-ietf-ipsec-arch-sec-04.txt>
>  o IP Authentication Header
> 	<draft-ietf-ipsec-auth-header-05.xt>
>  o The Use of HMAC-MD5-96 within ESP and AH 
> 	<draft-ietf-ipsec-auth-hmac-md5-96-03.txt>
>  o The Use of HMAC-SHA-1-96 within ESP and AH 
> 	<draft-ietf-ipsec-auth-hmac-sha196-03.txt>
>  o The ESP DES-CBC Cipher Algorithm With Explicit IV 
> 	<draft-ietf-ipsec-ciph-des-expiv-02.txt> 
>  o IP Encapsulating Security Payload (ESP)
> 	<draft-ietf-ipsec-esp-v2-04.txt>
>  o The Internet IP Security Domain of Interpretation for ISAKMP 
> 	<draft-ietf-ipsec-ipsec-doi-08.txt> 
>  o Internet Security Association and Key Management Protocol (ISAKMP) 
> 	<draft-ietf-ipsec-isakmp-09.txt> 
>  o The Internet Key Exchange (IKE)
> 	<draft-ietf-ipsec-isakmp-oakley-07.txt>
>  o The NULL Encryption Algorithm and Its Use With IPsec 
> 	<draft-ietf-ipsec-ciph-null-00.txt> 
> The IESG will also consider publication of the following
> Internet-Drafts as Informational RFCs:
>  o IP Security Protocol Working Group to consider IP Security Document
>    Roadmap
> 	<draft-ietf-ipsec-doc-roadmap-02.txt>
>  o The OAKLEY Key Determination Protocol
> 	<draft-ietf-ipsec-oakley-02.txt> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the 
> or mailing lists by April 11, 1998.
> Files can be obtained via:
> t
> t