[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Death to AH (was Re: SA identification)

So does ESP with Authentication and NULL-encryption.

-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
References: