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

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

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

On Mar 9, 9:56*pm, Dave Uhring <daveuhr...@yahoo.com> 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?

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

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

On Sun, 9 Mar 2008, in the Usenet newsgroup comp.os.linux.networking, in article
<abcae298-eeec-4e52-a9f9-62f6450834a3@x41g2000hsb.googlegroups.com>, 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

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
> <abcae298-eeec-4e52-a9f9-62f6450834a3@x41g2000hsb.googlegroups.com>, 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/

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