RE: [LinkSec] http://www.ieee802.org/linksec/Meetings/Jan03/Seaman_1_0103.pdf
I'm not sure that much value will be placed on preventing DoS attacks where
an intruder has to gain access to physicall secured media to start the
attack. If the media are not physically secured then there are so many other
ways to mount a DoS attack, from physical layer jamming to bogus MAC control
and configuration frames that I think the task would never get done. On the
other hand if we get some DoS protection for almost free then it is worth
having. If the DoS attack is through refular network access ports then the
best approach is usually to charge for it.
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 4:21 PM
> To: mick_seaman@ieee.org
> Cc: stds-802-linksec@ieee.org
> Subject: 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
> > >
> > >
>
>