[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Death to AH (was Re: SA identification)
True. But you can always look inside the ESP data and check if the
data _looks_ reasonable. I mean, a TCP or UDP header is fairly
distinctive :) You just aren't guaranteed that this will work
at all times.
-derek
"Steven M. Bellovin" <smb@research.att.com> writes:
> 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
>
>
--
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: