[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Death to AH (was Re: SA identification)
In message <sjmy9t4khhm.fsf@rcn.ihtfp.org>, Derek Atkins writes:
>So does ESP with Authentication and NULL-encryption.
Yes, but it's not context-free -- unless you know a priori that null
encryption is being used, you can't monitor it.
This is the one point I'll concede to the AH proponents...
>
>-derek
>
>"John Lowry" <jlowry@bbn.com> writes:
>
>> AH is likely to be attractive to network operators
>> who are running intrusion detection systems and virus
>> checkers at sub-domain (and less frequently at domain) boundaries.
>> It provides authentication while preserving the ability to
>> watch the traffic.
>>
>> A minor point but ...
>>
>> John
>>
>> -----Original Message-----
>> From: owner-ipsec@lists.tislabs.com
>> [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Kopeikin, Roy A (Roy)
>> Sent: Thursday, April 12, 2001 10:10 AM
>> To: Stephen Kent; Peter Ford
>> Cc: ipsec@lists.tislabs.com
>> Subject: RE: Death to AH (was Re: SA identification)
>>
>>
>> Concerning use/need for AH:
>>
>> Do companies like iPASS use it? Their service allows you to login to their
>> POP from anywhere in the world. They encrypt and then authenticate this
>> access attempt (not sure they use IPSec AH today). Once this access is
>> authorized, they encrypt nothing, hence having no use for ESP.
>>
>> However the corporation subscribing to this service has no use for AH, butr
>> could be interested in using ESP. iPASS advertised it was compatible with
>> many VPN solutions, including IPSec ones.
>>
>> So could a company liek iPASS use ESP instead of AH for their service? What
>> about other VPN-access-vendors? What do they want?
>>
>> -----Original Message-----
>> From: Stephen Kent [mailto:kent@bbn.com]
>> Sent: Wednesday, April 11, 2001 1:02 PM
>> To: Peter Ford
>> Cc: ipsec@lists.tislabs.com
>> Subject: RE: Death to AH (was Re: SA identification)
>>
>>
>> Peter,
>>
>> ><snip>
>> >
>> >The issues I brought up against AH were based on several issues:
>> >
>> >AH is/was fully redundant, and therefore did nothing but bloat the size
>> >of an "IPSEC compliant" piece of software and hardware. There were
>> >Silicon vendors who told us that the combination of AH and other
>> >enveloping (ESP-NULL, tunneling, etc.) would blow the computational and
>> >datapipe budgets they had in their designs. One large silicon vendor
>> >asked us to consider not supporting AH in combination with other IPSEC
>> >and tunneling configurations. Lastly, AH would confuse the "best
>> >common practice" of deploying IPSEC - do you use AH or ESP with NULL
>> >crypto or .... Extending ESP was a superior way to address the
>> >requirements presented in the course of IPSEC development.
>>
>> AH is not fully redundant. It is fair to say that one can achieve
>> ALMOST ALL the features of AH through the use of tunnel mode ESP,
>> sans encryption, but the two are not exactly equivalent. Presumably
>> the argument we've having now is determining whether the situations
>> where AH offers unique services warrant keeping it as part of the
>> IPsec suite, in a mandatory capacity.
>>
>> Your reference to the difficulty chip vendors envisioned in
>> supporting AH seemed to be a major motivation for the argument you
>> put forth, and that's an understandable concern. However, the IETF,
>> for better or worse, has usually not deferred to hardware vendor
>> concerns about implementation issues, relying on Moore's law to
>> address these issues over time. Instead, we often focus on software
>> implementation issues.
>>
>> I don't understand the reference to "best common practice .." above.
>>
>> Extending ESP was never seriously considered. No I-Ds on the topic
>> were ever published. There was considerable sentiment that making one
>> protocol (ESP) more complex as a means to avoid the need to implement
>> another protocol (AH) was not going to result in an overall simpler
>> system. I think this sentiment is accurate and persists today.
>>
>> >
>> >The arguments for AH:
>> >
>> >I) the document was already written and we are in a hurry because IPSEC
>> >can not happen until docs went to PS
>>
>> I believe the IETF meeting I referred to took place well before we
>> submitted 2401 as an RFC, so this argument seems a bit out of sync.
>>
>> >II)there are existing/working implementations
>>
>> true
>>
>> >III) and my favorite - and I paraphrase - this AH issue was already
>> >discussed, and most experts agree that AH was something akin to
>> >unnecessary/botch/etc., but since the pesky critter was still in the doc
>> >we needed to move on. It could be fixed at DS or later.
>>
>> I don't recall that.
>>
>> >IV) AH was the way to say "no data encryption in this packet" to comply
>> >with crypto wary governments.
>>
>> Still true, but given the IAB position on crypto, not a good rationale.
>>
>> >
>> >Jeff Schiller asked me if we/they left AH in the arch doc would
>> >Microsoft build versions of IPSEC without AH? To which I noted that
>> >this was not a proper question for a standards meeting and that for PC
>> >and Server implementations this was less of an issue, but for small
>> >devices (which MS also builds for) it could become a large issue.
>>
>> Unfortunately, my cursory examination of the MS implementation of
>> IPsec for PCs and servers last May revealed that it is not compliant
>> with 2401 anyway, e.g., it fails to provide a means for a user or
>> administrator to order the SPD entries, a very explicit requirement.
>> the lack of this facility makes it hard, if not impossible, for one
>> to determine how the implementation will process traffic.
>>
>> Steve
>
>--
> Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> Member, MIT Student Information Processing Board (SIPB)
> URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
> warlord@MIT.EDU PGP key available
>
--Steve Bellovin, http://www.research.att.com/~smb
Follow-Ups: