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

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

At 07:52 AM 4/13/01 , Steven M. Bellovin wrote:
>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...

Actually, I wouldn't concede quite so quickly.  AH is not context-free
either -- unless you know a priori that the packet AH is protecting is
not itself encrypted (e.g. ESP is not being used along with AH), you
can't monitor it either.

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