[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
state:
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 [SMTP:iesg-secretary@ns.ietf.org]
> Sent: Friday, March 20, 1998 12:08 PM
> Cc: ipsec@tis.com
> 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
> iesg@ietf.org or ietf@ietf.org mailing lists by April 11, 1998.
>
> Files can be obtained via:
>
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-arch-sec-04.txt
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-header-05.txt
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-md5-96-03.tx
> t
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-auth-hmac-sha196-03.tx
> t
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-des-expiv-02.txt
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v2-04.txt
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ipsec-doi-08.txt
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-09.txt
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-isakmp-oakley-07.txt
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-null-00.txt
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-doc-roadmap-02.txt
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipsec-oakley-02.txt
Follow-Ups: