RE: [LinkSec] http://www.ieee802.org/linksec/Meetings/Jan03/Seaman_1_0103.pdf
Mick:
The replay situation seems similar to IPsec. I asked Steve Kent why replay
protection was added to IPsec (it was not originally included). Steve said:
The function provides a form of DoS protection for the hosts behind
the IPsec device. If one assumes the device is at an enclave boundary,
and that it may be able to operate at line speed, then this is a useful
function because it prevents replays from clogging a LAN or wasting
cycles at possibly less powerful hosts in the enclave. It also may be
useful because it centralizes the AR function in what is arguably a
higher assurance point in the system, compared to most of the hosts.
These arguments seem to apply to bridges in the context that you propose.
Russ
At 01:23 PM 1/2/2003 -0800, Mick Seaman wrote:
>Russ,
>
>Thanks for the comments.
>
>On the subject of replay you are right, generally I am not concerned about
>replay being used to subvert a service for which most critical communication
>is using an ordering/sequencing/duplicate suppression protocol on top.
>However I would like to understand more about the threat that replay could
>pose at this layer, my imagination is not doing a great job on this subject
>so any examples (other than ones that simply result in denial of service)
>would help.
>
>I guess the big thing I didn't explain about the attractiveness of layer 2
>service is the dramatic rise in interest in providing layer 2 services in
>the service providers' world right now. In part this is because any
>involvement in anything above layer 2 carries a higher support (and
>especially training cost) for any provider who is not coming at this from
>the point of view of an ISP (and many who are), in part it is because
>organizations don't want their IP addressing plans interfered with simply
>because they are replacing a T1 link with an Etherenet (like) higher speed
>service, and in part as you say because there is quite a lot of non-IP
>protocol around (you'd be staggered how much). The 'non-interference with
>the customer' business goal of the service provider absolutely rules out
>having the effects of securing the LAN/Etherent access link from customer to
>provider propagate into the rest of the customers network (except to
>management consoles, but that's a separate story).
>
>Mick
>
>
> > -----Original Message-----
> > From: owner-stds-802-linksec@majordomo.ieee.org
> > [mailto:owner-stds-802-linksec@majordomo.ieee.org]On Behalf Of Russ
> > Housley
> > Sent: Thursday, January 02, 2003 12:35 PM
> > To: stds-802-linksec@ieee.org
> > Subject: [LinkSec]
> > http://www.ieee802.org/linksec/Meetings/Jan03/Seaman_1_0103.pdf
> >
> >
> >
> > I have a few comments on Mick's paper.
> >
> > Why link layer? on page 2. There is another reason. Not all
> > networks run
> > IP. Layer 2 offers a way to secure these other protocol
> > suites without
> > resorting to tunneling.
> >
> > Additional threats on page 4. In this section, you do not
> > explain your
> > reason for discarding a large collection of threats. Most of
> > them are
> > pretty obvious, but I do not think that the reason for
> > omitting replay is
> > obvious. In this scenario, the human user is a guest with a laptop
> > connecting to the host's LAN. Is the reason that you omit
> > replay that a
> > LAN provides a connectionless service? If not, please explain.
> >
> > Russ
> >
> >