[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Increased sequence number in ESP/AH
Sandy,
>"Steven M. Bellovin" wrote:
> >
> > In message <3A6DF166.60200CD1@columbia.sparta.com>, Andrea
>Colegrove writes:
> > >Steve,
> > > How does this address freshness (anti-replay)?
> > >
> > > Is this intended only as a useful feature for high-speed
>devices that may
> > >need additional SA lifetime?
> > >
> >
> > OC-192 -- deployed in some of today's backbones -- is roughly 1
> > gigabyte/second. Multiply by whatever you think is the average packet
> > size, and multiply again by 4 -- but it's not a large number for the
> > duration of an SA.
> >
> > --Steve Bellovin, http://www.research.att.com/~smb
>
>Yes, but do we expect those backbone devices to be doing IPSEC?
>Perhaps a limited
>amount for management functions -- remote admin login, ICMP, routing
>protocols --
>but I wouldn't expect them to be doing it for bulk traffic.
>
>Methinks bulk traffic encryption needs to be as near end-to-end as
>practical, if not
>on the end user systems, then on local routers and firewalls. Almost
>by definition,
>that excludes backbone routers. You want them just shuffling
>packets. Routing is
>hard enough without adding IPSEC to that mix.
>
>OC-3 is the largest pipe I'd expect near enough to the edges that we
>want to see
>IPSEC on it. 155 Mbit/sec, ~ 20 Mbyte, certainly less than 1 M packets/sec, so
>over an hour between re-keyinga. No problem.
>
>If we're contemplating any changes to the protocol, we want some that bring us
>nearer to the end-to-end goal, IPSEC on end-point systems.
Some of my clients anticipate OC 192 pipes to their sites in the next
couple fo years, if not sooner, and thus a security gateway at the
periphery of such sites needs to be able to deal with very high speed
flows of the sort that motivate this proposal.
steve
References: