Is an ARP Flooding possible? - Networking

This is a discussion on Is an ARP Flooding possible? - Networking ; Is there a possibility of a DoS attack if an attacker sends traffic to an IP which does not exists? So, does it always flood the ARP query on getting any of such traffic? It doesn't matter whether there are ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Is an ARP Flooding possible?

  1. Is an ARP Flooding possible?

    Is there a possibility of a DoS attack if an attacker sends traffic to
    an IP which does not exists? So, does it always flood the ARP query on
    getting any of such traffic? It doesn't matter whether there are
    switches in the subnet. Does the router need to flood all switches or
    just send to the switch which contains the corresponding subnet? I
    mean, suppose that there is a router and a number of switches
    connected to it on either sides (call these the left and right sides)
    So when someone keeps sending a packet to a non-existent IP on the
    right side, will the router keep flooding all the switches or is there
    a mechanism at the router level or the switch level to prevent this
    attack?

    Thanks

  2. Re: Is an ARP Flooding possible?

    On Sun, 09 Mar 2008 19:35:11 -0700, Legend wrote:

    homework questions which have *nothing* to do with Linux.

  3. Re: Is an ARP Flooding possible?

    On Mar 9, 9:56*pm, Dave Uhring wrote:
    > On Sun, 09 Mar 2008 19:35:11 -0700, Legend wrote:
    >
    > homework questions which have *nothing* to do with Linux.


    It has something to do with Networking atleast and I'm not sure if its
    a homework question for someone but I just got this doubt while
    looking at some router architectures. Anyways if its a pure networking
    question and not related to this newsgroup, would you be kind enough
    in suggesting another place where I could post this please?

  4. Re: Is an ARP Flooding possible?

    On Sun, 9 Mar 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article <11b19684-f36a-486f-85a4-332a6b1bd958@h25g2000hsf.googlegroups.com>,
    Legend wrote:

    >Is there a possibility of a DoS attack if an attacker sends traffic
    >to an IP which does not exists?


    To an _extremely_minor_ extent, yes. You'll want to see RFC1122 Section
    2.3.2 and RFC1812 Section 3.3.2 for details, as well as RFC0826:

    0826 Ethernet Address Resolution Protocol: Or Converting Network
    Protocol Addresses to 48.bit Ethernet Address for Transmission on
    Ethernet Hardware. D. Plummer. November 1982. (Format: TXT=21556
    bytes) (Also STD0037) (Status: STANDARD)

    1122 Requirements for Internet Hosts - Communication Layers. R.
    Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updated
    by RFC1349, RFC4379) (Also STD0003) (Status: STANDARD)

    1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
    (Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated
    by RFC2644) (Status: PROPOSED STANDARD)

    >So, does it always flood the ARP query on getting any of such traffic?
    >It doesn't matter whether there are switches in the subnet.


    ARP is a link level broadcast - so it would go to all switches/hosts
    on the subnet. But a well behaved router (or regular host) will not
    flood the network.

    >Does the router need to flood all switches or just send to the switch
    >which contains the corresponding subnet? I mean, suppose that there is
    >a router and a number of switches connected to it on either sides
    >(call these the left and right sides)


    Assumption - left and right sides are different subnets SUCH AS
    192.168.1.0/24 and 192.168.3.0/24.

    >So when someone keeps sending a packet to a non-existent IP on the
    >right side, will the router keep flooding all the switches or is there
    >a mechanism at the router level or the switch level to prevent this
    >attack?


    It will send it only to the switches on the "right" side (because it
    knows the IP it's looking for isn't on the "left" side). If you read
    RFC1122, you'll find the _recommended_ method is to ARP once per
    second MAXIMUM per IP address, and the actual technique varies from
    this recommendation. Some systems send an ARP packet at a variable
    rate - one router I'm using sends 3 ARP packets at 5 second intervals,
    and two more at 15 second intervals. If no reply is received, and the
    attacker tries again, the attacker will receive an immediate ICMP Type
    3 Code 1 (host unreachable) because the router knows the host isn't
    answering ARPs. This 'unreachable' entry expires off the cache
    normally in about a minute - though this is a configurable option. So
    with this router, the "flood" consists of five packets of 60 octets
    each, per address, per minute. Given that even the ancient 10Base$FOO
    Ethernet can easily cope with millions of times that rate...

    Old guy

  5. Re: Is an ARP Flooding possible?

    Thank you so much for the response. That was exactly what I was
    looking for. I was able to understand the way the routers were
    functioning in the scenario but the only doubt I had was, if someone
    keeps sending packets to a non-existent IP, I was not sure if the
    router will keep sending ARP requests. If that was the case, then what
    I was thinking was it would lead to an ARP flooding or some other
    attack. But I think your answer explains it very clearly. Also thank
    you for giving out an example. That makes it even more clearer. Also,
    thanks to Joseph who had mailed me a similar explanation. Now, I'll
    read the RFC1122 - looks really interesting to me Thank You
    again...

    On Mar 9, 10:49*pm, ibupro...@painkiller.example.tld (Moe Trin) wrote:
    > On Sun, 9 Mar 2008, in the Usenet newsgroup comp.os.linux.networking, in
    > article <11b19684-f36a-486f-85a4-332a6b1bd...@h25g2000hsf.googlegroups.com>,
    >
    > Legend wrote:
    > >Is there a possibility of a DoS attack if an attacker sends traffic
    > >to an IP which does not exists?

    >
    > To an _extremely_minor_ extent, yes. You'll want to see RFC1122 Section
    > 2.3.2 and RFC1812 Section 3.3.2 for details, as well as RFC0826:
    >
    > * 0826 Ethernet Address Resolution Protocol: Or Converting Network
    > * * * *Protocol Addresses to 48.bit Ethernet Address for Transmission on
    > * * * *Ethernet Hardware. D. Plummer. November 1982. (Format: TXT=21556
    > * * * *bytes) (Also STD0037) (Status: STANDARD)
    >
    > * 1122 Requirements for Internet Hosts - Communication Layers. R.
    > * * * *Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updated
    > * * * *by RFC1349, RFC4379) (Also STD0003) (Status: STANDARD)
    >
    > * 1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
    > * * * *(Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated
    > * * * *by RFC2644) (Status: PROPOSED STANDARD)
    >
    > >So, does it always flood the ARP query on getting any of such traffic?
    > >It doesn't matter whether there are switches in the subnet.

    >
    > ARP is a link level broadcast - so it would go to all switches/hosts
    > on the subnet. But a well behaved router (or regular host) will not
    > flood the network.
    >
    > >Does the router need to flood all switches or just send to the switch
    > >which contains the corresponding subnet? I mean, suppose that there is
    > >a router and a number of switches connected to it on either sides
    > >(call these the left and right sides)

    >
    > Assumption - left and right sides are different subnets SUCH AS
    > 192.168.1.0/24 and 192.168.3.0/24.
    >
    > >So when someone keeps sending a packet to a non-existent IP on the
    > >right side, will the router keep flooding all the switches or is there
    > >a mechanism at the router level or the switch level to prevent this
    > >attack?

    >
    > It will send it only to the switches on the "right" side (because it
    > knows the IP it's looking for isn't on the "left" side). If you read
    > RFC1122, you'll find the _recommended_ method is to ARP once per
    > second MAXIMUM per IP address, and the actual technique varies from
    > this recommendation. Some systems send an ARP packet at a variable
    > rate - one router I'm using sends 3 ARP packets at 5 second intervals,
    > and two more at 15 second intervals. If no reply is received, and the
    > attacker tries again, the attacker will receive an immediate ICMP Type
    > 3 Code 1 (host unreachable) because the router knows the host isn't
    > answering ARPs. *This 'unreachable' entry expires off the cache
    > normally in about a minute - though this is a configurable option. *So
    > with this router, the "flood" consists of five packets of 60 octets
    > each, per address, per minute. Given that even the ancient 10Base$FOO
    > Ethernet can easily cope with millions of times that rate...
    >
    > * * * * Old guy



  6. Re: Is an ARP Flooding possible?

    On Sun, 9 Mar 2008, in the Usenet newsgroup comp.os.linux.networking, in article
    , Legend
    wrote:

    >Now, I'll read the RFC1122 - looks really interesting to me Thank
    >You again...


    You're welcome. A suggestion for you. Go to ftp://ftp.isi.edu/in-notes/
    and get a copy of the rfc-index.txt file

    [compton ~]$ zcat rfcs/rfc-index* | sed 's/^$/\%/' | tr -d '\n' | tr
    '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' | sed
    's/.*Status: //' | tr -d '\)' | sort | uniq -c | column
    145 BEST CURRENT PRACTICE 1564 INFORMATIONAL
    135 DRAFT STANDARD 1667 PROPOSED STANDARD
    288 EXPERIMENTAL 88 STANDARD
    210 HISTORIC 909 UNKNOWN
    [compton ~]$ zcat rfcs/rfc-index.txt* | sed 's/^$/\%/' | tr -d '\n' | tr
    '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -c 'Not Issued'
    80
    [compton ~]$

    Of the 5000+ RFCs that have been issued/released, only 88 are classified
    as "STANDARD", though a lot more are drafts of standards or proposed as
    standards. Looking at the titles often gives an indication of some highly
    useful information. Just be a little wary of those that are dated April
    1 for some reasons:

    1097 Telnet subliminal-message option. B. Miller. Apr-01-1989.
    (Format: TXT=5490 bytes) (Status: UNKNOWN)

    1925 The Twelve Networking Truths. R. Callon. Apr-01-1996. (Format:
    TXT=4294 bytes) (Status: INFORMATIONAL)

    3093 Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner.
    April-01-2001. (Format: TXT=22405 bytes) (Status: INFORMATIONAL)

    Old guy

  7. Re: Is an ARP Flooding possible?

    On 03/11/2008 01:31 AM, Moe Trin wrote:
    > On Sun, 9 Mar 2008, in the Usenet newsgroup comp.os.linux.networking, in article
    > , Legend
    > wrote:
    >
    >> Now, I'll read the RFC1122 - looks really interesting to me Thank
    >> You again...

    >
    > You're welcome. A suggestion for you. Go to ftp://ftp.isi.edu/in-notes/
    > and get a copy of the rfc-index.txt file
    >
    > [compton ~]$ zcat rfcs/rfc-index* | sed 's/^$/\%/' | tr -d '\n' | tr
    > '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -v 'Not Issued' | sed
    > 's/.*Status: //' | tr -d '\)' | sort | uniq -c | column
    > 145 BEST CURRENT PRACTICE 1564 INFORMATIONAL
    > 135 DRAFT STANDARD 1667 PROPOSED STANDARD
    > 288 EXPERIMENTAL 88 STANDARD
    > 210 HISTORIC 909 UNKNOWN
    > [compton ~]$ zcat rfcs/rfc-index.txt* | sed 's/^$/\%/' | tr -d '\n' | tr
    > '%' '\n' | grep '^[0-9]' | tr -s ' ' | grep -c 'Not Issued'
    > 80
    > [compton ~]$
    >
    > Of the 5000+ RFCs that have been issued/released, only 88 are classified
    > as "STANDARD", though a lot more are drafts of standards or proposed as
    > standards. Looking at the titles often gives an indication of some highly
    > useful information. Just be a little wary of those that are dated April
    > 1 for some reasons:
    >
    > 1097 Telnet subliminal-message option. B. Miller. Apr-01-1989.
    > (Format: TXT=5490 bytes) (Status: UNKNOWN)
    >
    > 1925 The Twelve Networking Truths. R. Callon. Apr-01-1996. (Format:
    > TXT=4294 bytes) (Status: INFORMATIONAL)
    >
    > 3093 Firewall Enhancement Protocol (FEP). M. Gaynor, S. Bradner.
    > April-01-2001. (Format: TXT=22405 bytes) (Status: INFORMATIONAL)
    >
    > Old guy


    Moreover, it is quite confusing which of the RFC are interrelated; what
    the heck RFC numbers are doing; all these I think, are useless version
    numbers. Which of the RFC's succeeds and, or obsoletes which one, are
    few questions have not been addressed by any of these RFC's.

    --
    Dr Balwinder S "bsd" Dheeman Registered Linux User: #229709
    Anu'z Linux@HOME (Unix Shoppe) Machines: #168573, 170593, 259192
    Chandigarh, UT, 160062, India Gentoo, Fedora, Debian/FreeBSD/XP
    Home: http://cto.homelinux.net/~bsd/ Visit: http://counter.li.org/

  8. Re: Is an ARP Flooding possible?

    On Tue, 11 Mar 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article <5b9ha5xt5l.ln2@news.sebs.org.in>, Balwinder S Dheeman wrote:

    >Moe Trin wrote:


    >> A suggestion for you. Go to ftp://ftp.isi.edu/in-notes/ and get a
    >> copy of the rfc-index.txt file


    >> Of the 5000+ RFCs that have been issued/released, only 88 are
    >> classified as "STANDARD", though a lot more are drafts of standards
    >> or proposed as standards. Looking at the titles often gives an
    >> indication of some highly useful information.


    >Moreover, it is quite confusing which of the RFC are interrelated;
    >what the heck RFC numbers are doing; all these I think, are useless
    >version numbers. Which of the RFC's succeeds and, or obsoletes which
    >one, are few questions have not been addressed by any of these RFC's.


    2026 The Internet Standards Process -- Revision 3. S. Bradner. October
    1996. (Format: TXT=86731 bytes) (Obsoletes RFC1602, RFC1871)
    (Updated by RFC3667, RFC3668, RFC3932, RFC3979, RFC3978) (Also
    BCP0009) (Status: BEST CURRENT PRACTICE)

    RFC2026 would be a good starting place. Then look at that rfc-index.txt
    file I mentioned above (where this entry came from)

    ftp> dir rfc-in*
    200 PORT command successful.
    150 Opening ASCII mode data connection for /bin/ls.
    -rw-r--r-- 1 ftpuser ftpusers 4037 Mar 10 02:30 rfc-index-latest.txt
    -rw-r--r-- 1 ftpuser ftpusers 862967 Mar 10 07:06 rfc-index.txt
    -rw-r--r-- 1 ftpuser ftpusers 6260122 Mar 10 02:40 rfc-index.xml
    -rw-r--r-- 1 ftpuser ftpusers 14316 Aug 3 2006 rfc-index.xsd
    226 Listing completed.

    (that was Monday evening UTC), and a lot will become obvious. (Note that
    virtually all of the 5000+ RFCs are also in that directory.) The listing
    for RFC2026 above shows that it replaced RFC1602 and RFC1871...

    1602 The Internet Standards Process -- Revision 2. Internet
    Architecture Board, Internet Engineering Steering Group. March 1994.
    (Format: TXT=88465 bytes) (Obsoletes RFC1310) (Obsoleted by RFC2026)
    (Updated by RFC1871) (Status: INFORMATIONAL)

    1871 Addendum to RFC 1602 -- Variance Procedure. J. Postel. November
    1995. (Format: TXT=7747 bytes) (Obsoleted by RFC2026) (Updates
    RFC1602, RFC1603) (Status: HISTORIC)

    and in turn has been updated by RFC3667, RFC3668, RFC3932, RFC3979, and
    RFC3978.

    3667 IETF Rights in Contributions. S. Bradner. February 2004. (Format:
    TXT=43297 bytes) (Obsoleted by RFC3978) (Updates RFC2026) (Status:
    BEST CURRENT PRACTICE)

    3668 Intellectual Property Rights in IETF Technology. S. Bradner.
    February 2004. (Format: TXT=41365 bytes) (Obsoleted by RFC3979)
    (Updates RFC2026, RFC2028) (Status: BEST CURRENT PRACTICE)

    3932 The IESG and RFC Editor Documents: Procedures. H. Alvestrand.
    October 2004. (Format: TXT=17093 bytes) (Updates RFC2026, RFC3710)
    (Also BCP0092) (Status: BEST CURRENT PRACTICE)

    and so on. Yes, it is not as simple as it could be, but given the world
    wide source of the documents and the fact that the subjects are still
    evolving, it's probably the best you can do. I normally grab a copy of
    the rfc-index.txt file monthly, and do a 'diff' to the previous version
    to see what has changed. In the past, I also spent several evenings
    just scanning this file to see what was there, and made a list of those
    RFCs that I needed more information about. Also note that these
    particular documents also MAY list a 'BCP' number - and that is a
    separate numbering scheme which consists of the "latest version" of a
    referred document. (There is also a 'STD' series for STANDARDs in
    addition to the BCP series for BEST CURRENT PRACTICE documents.)

    I'm not sure what you mean by "what the heck RFC numbers are doing".
    Are you referring to the now obsolete RFC1700?

    1700 Assigned Numbers. J. Reynolds, J. Postel. October 1994. (Format:
    TXT=458860 bytes) (Obsoletes RFC1340) (Obsoleted by RFC3232)
    (Status: HISTORIC)

    RFC3232 replaced this family of "Assigned Numbers" documents in 2002
    with a series of web pages - try http://www.iana.org/assignments/

    Old guy

+ Reply to Thread