[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: Security Architecture for the Internet Protocol to Proposed Standard
Peter,
>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.
Yes, AH is ugly, but one cannot achieve the same effects via ESP, even now
that we have an authentication-only mode of ESP. If one requires integrity
and authenticity for portions of the IP header, and one wants to do this
without tunneling, then AH is the protocol of choice. As others have
noted, there have been vocal supporters for AH in the past, hence its
continued existence and its status as a required part of IPsec.
>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.
A pure encapsulation approach would be nicer, in many respects. I'd have
to defer to Ran on why that approach was not considered viable.
>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.
Yes, this can happen, in the case of a unidirectional data flow. IPsec has
avoided triggering SA establishment based on receipt of unsolicited
traffic, to minimize denial of service attacks, so the obvious solution is
not one that the WG wishes to pursue. More sophisitcated approaches are
being explored, as you note. Is the spec incomplete? Yes, in this respect,
and we also don't support broadcast in a scaleable fashion, and there are
several other features we would like to have now but the WG has elected to
postpone these for the next pass on the protocols.
>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.
It could be renamed, but a strong Republication faction will be
disappointed :-)!
>
>If AH moves to PS, customers will expect it to be part of ALL
>implementations. This is the time to simplify IPSEC.
Customers should expect Ah in all implementations; it's an integral part of
the current standard. If we let folks pick and choose only those parts
that they feel are relevant to them, their products, their market, then we
will limit interoperability. That's not consistent with the general IETF
standards approach.
Steve
References: