RE: CSMA/CD

From: K sPecial (xzziroz_at_linuxmail.org)
Date: 08/22/03

  • Next message: Matthew F. Caldwell: "RE: SoBig and some info"
    To: ajfomania@hotmail.com, "Security Focus" <security-basics@securityfocus.com>
    Date: Fri, 22 Aug 2003 12:35:17 +0800
    
    

    I had came up with this exact idea at a point in reading, Allthough I basicly did not look to much further when I realized that CMSA/CD is incorperated in a chip on the Network card and that the signal (i believe) is an electrical difference and nothing to do with a packet whats so ever. I hope this helps your compulsing.

    --K-sPecial

    ----- Original Message -----
    From: "David Gillett" <gillettdavid@fhda.edu>
    Date: Thu, 21 Aug 2003 15:59:04 -0700
    To: "'. .'" <ajfomania@hotmail.com>, <Security-basics@securityfocus.com>
    Subject: RE: CSMA/CD

    > Before a CSMA/CD device transmits, it listens to hear that the
    > wire is clear. (If it isn't, it waits for a while and listens
    > again.)
    > There's a potential race condition where two (or more!) devices
    > listen, find that the wire is clear, and both decide to transmit.
    > Part of resolving this race condition is for each frame transmission
    > to start with a "pad" of known filler.
    > The CD (collision detection) piece comes into play at that point.
    > If no race condition has occurred, the part of the hardware that
    > listens to the wire will hear only its own filler. Anyone who
    > shows up late and listens to hear if the wire is clear will also
    > hear the filler, and wait.
    > If the listener hears anything else, then it must be because
    > someone else is ALSO putting out filler on the wire (i.e., the
    > race condition occurred); since there's only one "band", the two
    > transmissions "collide" and no listener can separate them.
    > Having detected a collision, the device aborts transmission of
    > the frame data, waits some random time, and goes back to listening
    > for a clear line. (The wait time is randomized so the same pair
    > of devices don't collide again on the same frames.)
    >
    >
    > > If the trying host gets 15 jam signals at one time, it times out.
    >
    > I think the spec is that if 15 retry attempts on a frame all
    > encounter collisions, the frame is dropped. That's not quite the
    > same thing.
    >
    > > Is there any possibility to write a program that sends jam
    > > signals to other hosts within the same broadcast domain until
    > > they timed out and died?
    >
    > The filler isn't aimed at any particular host, it's visible to
    > everyone on the *collision* domain. There isn't a way to do this
    > into other collision domains, even if they happen to be in the
    > same broadcast domain.
    > At worst, you could issue a stream of filler and deny service to
    > every other device on the collision domain. They wouldn't "die",
    > they'd just be forced to discard frames that couldn't be sent.
    >
    > > Does this mean that IF you were to write this program, you'd
    > > actually need to rewrite a part of the tcp/ip protocol stack?
    >
    > As someone else has pointed out, this is probably normally done
    > as part of the Ethernet port hardware. At best, it might be in
    > driver code. Since Ethernet can be used to carry AppleTalk,
    > DECNet, IPX, etc, it's not in the TCP/IP part of the stack.
    >
    > > Isn't this a big issue?
    >
    > No. A Denial-of-Service that, by definition, has to include
    > yourself, and requires physical access to the target LAN segment,
    > is somehow not that interesting to attackers.
    >
    > David Gillett
    >
    >
    > > -----Original Message-----
    > > From: . . [mailto:ajfomania@hotmail.com]
    > > Sent: August 21, 2003 04:08
    > > To: Security-basics@securityfocus.com
    > > Subject: CSMA/CD
    > >
    > >
    > > Hi there!
    > > I'm currently reading a CCNA book, and I've got some
    > > questions I can't find
    > > an answer to.
    > > The Carrier Sense Multiple Access with Collision Detection
    > > checks if there
    > > is any traffic on the wire and then starts to send the host's
    > > data, if
    > > someone tryes to send at the same time, the sending host
    > > sends the "trying"
    > > host a jam signal that would make the trying host to wait.If
    > > the trying host
    > > get's 15 jam signals at one time, it times out.
    > >
    > > Some questions came up at this chapter. Is there any
    > > possibility to write a
    > > program that sends jam signals to other hosts within the same
    > > broadcast
    > > domain until they timed out and died ? Does this mean that IF
    > > you where to
    > > write this program, actually needed to rewrite a part of the tcp/ip
    > > protocol stack ? Isn't this a big issue?
    > >
    > > Sorry for my bad english..
    > >
    > > Best Regards: Fredrik Wessberg
    > >
    > > _________________________________________________________________
    > > Lättare att hitta drömresan med MSN Resor http://www.msn.se/resor/
    > >
    > >
    > > --------------------------------------------------------------
    > > -------------
    > > --------------------------------------------------------------
    > > --------------
    > >
    >
    >
    > ---------------------------------------------------------------------------
    > ----------------------------------------------------------------------------
    >

    -- 
    ______________________________________________
    http://www.linuxmail.org/
    Now with e-mail forwarding for only US$5.95/yr
    Powered by Outblaze
    ---------------------------------------------------------------------------
    ----------------------------------------------------------------------------
    

  • Next message: Matthew F. Caldwell: "RE: SoBig and some info"