Mailing List Archive

I'm surprised I haven't seen QoS mentioned! If you're teaching college
students, you might want to go over stuff that directly relates to what
they're doing at home, or misconceptions they might make in a small
WAN/ISP environment.

*Why disabling ICMP doesn't increase security and only hurts the web* *(path
MTU discovery, diagnostics)
*How NAT breaks end-to-end connectivity (fun one..., took me hours to
explain to an old boss why doing NAT at the ISP level was horrendously
wrong)
*Not to be afraid of ACLs on an edge router. Understanding what
does/doesn't affect cpu utilization
*Layer 3 Switch vs Router. Old concepts like switch vs router need to be
clarified...
*When vendors and numbers lie ;) aka *oversubscription*!
*MAC is not security
*Irrelevant security concepts (smurf attacks, ping of death). More focus
should be on real modern day security concerns, like layer 7 exploits,
router software 0days, VLAN hopping, and UDP floods and BGP spoofing. This
might be a good place to explain why downloading IOS firmware from
thepiratebay is a bad idea :)

This is just coming from a sysadmin who likes to play with network gear and
once endured college networking classes.

Thanks!
Andreas


On Wed, Feb 15, 2012 at 1:47 PM, John Kristoff <jtk@cymru.com> wrote:

> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers. Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
>

Or more to the point, it is a misconception that traffic is
symetrical (the path out and the path back are the same) whereas in
the present network, symetrical paths are the exception rather than
the rule, especially as your radius increases.

On Wed, Feb 15, 2012 at 07:17:57PM -0500, Lee wrote:
> traceroute shows _a_ path. Your packets might have taken a different
> path. (& the return traffic yet another)


---
Wayne Bouchard
web@typo.org
Network Dude
http://www.typo.org/~web/

On Thu, 16 Feb 2012, Wayne E Bouchard wrote:

> Or more to the point, it is a misconception that traffic is
> symetrical (the path out and the path back are the same) whereas in
> the present network, symetrical paths are the exception rather than
> the rule, especially as your radius increases.

To add to that, I feel pretty sure in stating that many of the people on
this list, at one point or another, have either had people tell them that
asymmetric routing is "bad", or have had to explain why asymmetric routing
across 'the Internet' is not "bad", even if it can make troubleshooting a
'network problem' somewhat more involved. The path from A to B is not
necessarily the same as the path from B to A.

jms

Alot of people are unclear on how hard it is for someone to sniff internet
traffic if the aren't physically located at or near one of the endpoints
IE: connected to the same access point or same switch.

2012/2/15 John Kristoff <jtk@cymru.com>

> Hi friends,
>
> As some of you may know, I occasionally teach networking to college
> students and I frequently encounter misconceptions about some aspect
> of networking that can take a fair amount of effort to correct.
>
> For instance, a topic that has come up on this list before is how the
> inappropriate use of classful terminology is rampant among students,
> books and often other teachers. Furthermore, the terminology isn't even
> always used correctly in the original context of classful addressing.
>
> I have a handful of common misconceptions that I'd put on a top 10 list,
> but I'd like to solicit from this community what it considers to be the
> most annoying and common operational misconceptions future operators
> often come at you with.
>
> I'd prefer replies off-list and can summarize back to the list if
> there is interest.
>
> John
>
>
>

Seems like dig doesn't always advertise a big enough buffer, I was having
the same issue as you. If you set the buffer size on the command line it
works as directed.

Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58
;; Truncated, retrying in TCP mode.
;; Connection to 149.20.64.58#53(149.20.64.58) for
edns-v4-ok.isc.orgfailed: connection refused.
Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58+bufsize=4096

; <<>> DiG 9.7.3-P3 <<>> edns-v4-ok.isc.org txt @149.20.64.58 +bufsize=4096
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18209
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;edns-v4-ok.isc.org. IN TXT

;; ANSWER SECTION:
edns-v4-ok.isc.org. 0 IN TXT "EDNS-4096-OK" "EDNS-4096-OK"
"EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK"
<snip>
"EDNS-4"

;; Query time: 176 msec
;; SERVER: 149.20.64.58#53(149.20.64.58)
;; WHEN: Fri Feb 17 10:22:08 2012
;; MSG SIZE rcvd: 4096




On 17 February 2012 05:53, Phil Regnauld <regnauld@nsrc.org> wrote:

> Borderline dns-ops, sorry folks! - but this is interesting
> as we've been talking about ipv6 being operational, and this
> is part of it...
>
> Mark Andrews (marka) writes:
> >
> > If you are seeing TC between the resolver and the server and the TCP
> query is being answers then
> > something in the path is intercepting the DNS queries.
>
> TC is on the answer from the remote server to my resolver, so
> yeah, seems
> like something is messing with the packets.
>
> > > Don't see any v6 fragments (that'd be a problem since PF doesn't
> handle
> > > them on this host).
> >
> > You should see something like this on the wire. The second query is to
> answer
> > dig's query over TCP.
>
> I'm not seeing fragments as you are.
>
> Here's what I see:
>
> 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 52841
> TXT? edns-v6-ok.isc.org. (36)
> 14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561:
> 52841*-| 0/0/0 (36)
> 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flags
> [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS
> val 2571957531 ecr 0], length 0
> 14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flags
> [R.], seq 0, ack 1112939463, win 0, length 0
>
> Cheers,
> Phil
>
>


--
Daniel Griggs
Network Operations
e: daniel@fx.net.nz
d: +64 4 4989567

Right, asymmetric paths are the norm for many inter-provider
communications.
A related misconception is that asymmetric paths are problematic.
Another mis-conception related to path is that more (visible) hops are bad
with the corollary that routers introduce (significant) latency.
Of course, propagation delay is the most significant contributor to latency
in WAN environments (or serialization delay for low-speed links).

Tony

On Thu, Feb 16, 2012 at 3:35 PM, Wayne E Bouchard <web@typo.org> wrote:

> Or more to the point, it is a misconception that traffic is
> symetrical (the path out and the path back are the same) whereas in
> the present network, symetrical paths are the exception rather than
> the rule, especially as your radius increases.
>
> On Wed, Feb 15, 2012 at 07:17:57PM -0500, Lee wrote:
> > traceroute shows _a_ path. Your packets might have taken a different
> > path. (& the return traffic yet another)
>
>

In message <CA+ycCUOoLgwAMUn_aSBf8FFiPczWmt2oo7T45jOnqthJWx+xpg@mail.gmail.com>, Daniel Griggs writes:
> --001636c5b8ca93b4eb04b91b7066
> Content-Type: text/plain; charset=ISO-8859-1
>
> Seems like dig doesn't always advertise a big enough buffer, I was having
> the same issue as you. If you set the buffer size on the command line it
> works as directed.

Well you were supposed to ask your recursive server, not ask the
authoritative server directly. We were talking about testing the
path from the recursive server (which you may not have log in access
to) to the authoritative server. If you want to ask the authoritative
server directly then +edns=0 or +dnssec or +bufsize=4096 or you can
use dig from BIND 9.9.0 which sets the ad flag and enables edns
(version 0) by default.

% dig edns-v6-ok.isc.org txt
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.7.3-P3 <<>> edns-v6-ok.isc.org txt
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46198
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;edns-v6-ok.isc.org. IN TXT

;; ANSWER SECTION:
edns-v6-ok.isc.org. 0 IN TXT "EDNS-4096-OK" "EDNS-4096-OK" <snipped>

;; AUTHORITY SECTION:
edns-v6-ok.isc.org. 7199 IN NS edns-v6-ok.isc.org.

;; ADDITIONAL SECTION:
edns-v6-ok.isc.org. 7199 IN AAAA 2001:4f8:0:2::8

;; Query time: 174 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Feb 17 09:36:37 2012
;; MSG SIZE rcvd: 4127

%


> Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58
> ;; Truncated, retrying in TCP mode.
> ;; Connection to 149.20.64.58#53(149.20.64.58) for
> edns-v4-ok.isc.orgfailed: connection refused.
> Daniels-Mac-mini:~ daniel$ dig edns-v4-ok.isc.org txt @149.20.64.58+bufsize=4096
>
> ; <<>> DiG 9.7.3-P3 <<>> edns-v4-ok.isc.org txt @149.20.64.58 +bufsize=4096
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18209
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;edns-v4-ok.isc.org. IN TXT
>
> ;; ANSWER SECTION:
> edns-v4-ok.isc.org. 0 IN TXT "EDNS-4096-OK" "EDNS-4096-OK"
> "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK" "EDNS-4096-OK"
> <snip>
> "EDNS-4"
>
> ;; Query time: 176 msec
> ;; SERVER: 149.20.64.58#53(149.20.64.58)
> ;; WHEN: Fri Feb 17 10:22:08 2012
> ;; MSG SIZE rcvd: 4096
>
>
>
>
> On 17 February 2012 05:53, Phil Regnauld <regnauld@nsrc.org> wrote:
>
> > Borderline dns-ops, sorry folks! - but this is interesting
> > as we've been talking about ipv6 being operational, and this
> > is part of it...
> >
> > Mark Andrews (marka) writes:
> > >
> > > If you are seeing TC between the resolver and the server and the TCP
> > query is being answers then
> > > something in the path is intercepting the DNS queries.
> >
> > TC is on the answer from the remote server to my resolver, so
> > yeah, seems
> > like something is messing with the packets.
> >
> > > > Don't see any v6 fragments (that'd be a problem since PF doesn't
> > handle
> > > > them on this host).
> > >
> > > You should see something like this on the wire. The second query is to
> > answer
> > > dig's query over TCP.
> >
> > I'm not seeing fragments as you are.
> >
> > Here's what I see:
> >
> > 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 > 2001:4f8:0:2::8.53: 52841
> > TXT? edns-v6-ok.isc.org. (36)
> > 14:40:21.141948 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.64561:
> > 52841*-| 0/0/0 (36)
> > 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 > 2001:4f8:0:2::8.53: Flags
> > [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS
> > val 2571957531 ecr 0], length 0
> > 14:40:21.327895 IP6 2001:4f8:0:2::8.53 > 2001:2000:1080:d::2.53262: Flags
> > [R.], seq 0, ack 1112939463, win 0, length 0
> >
> > Cheers,
> > Phil
> >
> >
>
>
> --
> Daniel Griggs
> Network Operations
> e: daniel@fx.net.nz
> d: +64 4 4989567
>
> --001636c5b8ca93b4eb04b91b7066
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> <br>Seems like dig doesn&#39;t always advertise a big enough buffer, I was =
> having the same issue as you. If you set the buffer size on the command lin=
> e it works as directed.<br><br>Daniels-Mac-mini:~ daniel$ dig <a href=3D"ht=
> tp://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a> txt @<a href=3D"http://149.=
> 20.64.58">149.20.64.58</a><br>
> ;; Truncated, retrying in TCP mode.<br>;; Connection to 149.20.64.58#53(149=
> .20.64.58) for <a href=3D"http://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a>=
> failed: connection refused.<br>Daniels-Mac-mini:~ daniel$ dig <a href=3D"h=
> ttp://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a> txt @<a href=3D"http://149=
> .20.64.58">149.20.64.58</a> +bufsize=3D4096<br>
> <br>; &lt;&lt;&gt;&gt; DiG 9.7.3-P3 &lt;&lt;&gt;&gt; <a href=3D"http://edns=
> -v4-ok.isc.org">edns-v4-ok.isc.org</a> txt @<a href=3D"http://149.20.64.58"=
> >149.20.64.58</a> +bufsize=3D4096<br>;; global options: +cmd<br>;; Got answ=
> er:<br>
> ;; -&gt;&gt;HEADER&lt;&lt;- opcode: QUERY, status: NOERROR, id: 18209<br>;;=
> flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1<br>;; WA=
> RNING: recursion requested but not available<br><br>;; OPT PSEUDOSECTION:<b=
> r>
> ; EDNS: version: 0, flags:; udp: 4096<br>;; QUESTION SECTION:<br>;<a href=
> =3D"http://edns-v4-ok.isc.org">edns-v4-ok.isc.org</a>.=A0=A0=A0 =A0=A0=A0 I=
> N=A0=A0=A0 TXT<br><br>;; ANSWER SECTION:<br><a href=3D"http://edns-v4-ok.is=
> c.org">edns-v4-ok.isc.org</a>.=A0=A0=A0 0=A0=A0=A0 IN=A0=A0=A0 TXT=A0=A0=A0=
> &quot;EDNS-4096-OK&quot; &quot;EDNS-4096-OK&quot; &quot;EDNS-4096-OK&quot;=
> &quot;EDNS-4096-OK&quot; &quot;EDNS-4096-OK&quot; &quot;EDNS-4096-OK&quot;=
> <br>
> &lt;snip&gt;<br>&quot;EDNS-4&quot;<br><br>;; Query time: 176 msec<br>;; SER=
> VER: 149.20.64.58#53(149.20.64.58)<br>;; WHEN: Fri Feb 17 10:22:08 2012<br>=
> ;; MSG SIZE=A0 rcvd: 4096<br><br><br><br><br><div class=3D"gmail_quote">On =
> 17 February 2012 05:53, Phil Regnauld <span dir=3D"ltr">&lt;<a href=3D"mail=
> to:regnauld@nsrc.org">regnauld@nsrc.org</a>&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"> =A0 =A0 =A0 =A0Borderline dns-ops, sorry fo=
> lks! - but this is interesting<br>
> =A0 =A0 =A0 =A0as we&#39;ve been talking about ipv6 being operational, and=
> this<br>
> =A0 =A0 =A0 =A0is part of it...<br>
> <div class=3D"im"><br>
> Mark Andrews (marka) writes:<br>
> &gt;<br>
> &gt; If you are seeing TC between the resolver and the server and the TCP q=
> uery is being answers then<br>
> &gt; something in the path is intercepting the DNS queries.<br>
> <br>
> </div> =A0 =A0 =A0 =A0TC is on the answer from the remote server to my reso=
> lver, so yeah, seems<br>
> =A0 =A0 =A0 =A0like something is messing with the packets.<br>
> <div class=3D"im"><br>
> &gt; &gt; =A0 =A0 Don&#39;t see any v6 fragments (that&#39;d be a problem s=
> ince PF doesn&#39;t handle<br>
> &gt; &gt; =A0 =A0 them on this host).<br>
> &gt;<br>
> &gt; You should see something like this on the wire. =A0The second query is=
> to answer<br>
> &gt; dig&#39;s query over TCP.<br>
> <br>
> </div> =A0 =A0 =A0 =A0I&#39;m not seeing fragments as you are.<br>
> <br>
> =A0 =A0 =A0 =A0Here&#39;s what I see:<br>
> <br>
> 14:40:20.955876 IP6 2001:2000:1080:d::2.64561 &gt; 2001:4f8:0:2::8.53: 5284=
> 1 TXT? <a href=3D"http://edns-v6-ok.isc.org" target=3D"_blank">edns-v6-ok.i=
> sc.org</a>. (36)<br>
> 14:40:21.141948 IP6 2001:4f8:0:2::8.53 &gt; 2001:2000:1080:d::2.64561: 5284=
> 1*-| 0/0/0 (36)<br>
> 14:40:21.142259 IP6 2001:2000:1080:d::2.53262 &gt; 2001:4f8:0:2::8.53: Flag=
> s [S], seq 1112939462, win 65535, options [mss 1440,nop,wscale 6,sackOK,TS =
> val 2571957531 ecr 0], length 0<br>
> 14:40:21.327895 IP6 2001:4f8:0:2::8.53 &gt; 2001:2000:1080:d::2.53262: Flag=
> s [R.], seq 0, ack 1112939463, win 0, length 0<br>
> <br>
> =A0 =A0 =A0 =A0Cheers,<br>
> =A0 =A0 =A0 =A0Phil<br>
> <br>
> </blockquote></div><br><br clear=3D"all"><br>-- <br>Daniel Griggs<br>Networ=
> k Operations<br>e: <a href=3D"mailto:daniel@fx.net.nz" target=3D"_blank">da=
> niel@fx.net.nz</a><br>d: +64 4 4989567<br>
>
> --001636c5b8ca93b4eb04b91b7066--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

On 02/15/12 23:34, Owen DeLong wrote:
> I think one of the most damaging fundamental misconceptions which is
> not only rampant among students, but, also enterprise IT professionals
> is the idea that NAT is a security tool and the inability to conceive of the
> separation between NAT (header mutilation) and Stateful Inspection
> (policy enforcement).

Another misconception is that RFC 1918 somehow
implies/specifies/requires NAT. The idea of using private address
without NATing them seems to totally bewilder some people. And they
often can't wrap their heads around the possibility of routing RFC 1918
space internally and also not using NAT. (This causes them to be even
more confused at the fact that RFC 4193 specifies ULA for IPv6, but
there is no stateful NAT currently specified.)

Concepts/words that often get confused:

Difference between 'allocation' and 'assignment' in IP addressing.

Use of the word "IP" alone to mean "IP address," e.g.:

Person: "Does that server have an IP assigned?"
Me: "Yeah, it's got a whole stack."

Then, of course, there's the silly situation where people mean to say
"rogue" but they type "rouge" as in "rouge DHCP server," "rouge RA
advertiser," etc.

michael

Andreas Echavez wrote:

> *Why disabling ICMP doesn't increase security and only hurts the web* *(path
> MTU discovery, diagnostics)

That PMTUD works is a misconception.

> *How NAT breaks end-to-end connectivity (fun one..., took me
> hours to explain to an old boss why doing NAT at the ISP level
> was horrendously wrong)

That's another misconception.

While NAT breaks the end to end connectivity, it can be
restored by end systems by reversing translations by NAT,
if proper information on the translations are obtained
through some protocol such as UPnP.

Masataka Ohta

2012/2/16 Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>:
> Andreas Echavez wrote:
>> *How NAT breaks end-to-end connectivity (fun one..., took me
>>  hours to explain to an old boss why doing NAT at the ISP level
>>  was horrendously wrong)
>
> That's another misconception.
>
> While NAT breaks the end to end connectivity, it can be
> restored by end systems by reversing translations by NAT,
> if proper information on the translations are obtained
> through some protocol such as UPnP.
>
>                                        Masataka Ohta
>

UPnP can scale to about the size of an average home use, but it's
worth jack squat at the ISP level when NAT44 comes into play. UPnP is
not an ISP grade solution, it's a consumer one.

Josh Hoppes wrote:

>> While NAT breaks the end to end connectivity, it can be
>> restored by end systems by reversing translations by NAT,
>> if proper information on the translations are obtained
>> through some protocol such as UPnP.

> UPnP can scale to about the size of an average home use,

It depends on how you use UPnP and version of it.

E.g. security to control UPnP gateway is not a problem
if the gateway is configured statically.

> but it's
> worth jack squat at the ISP level when NAT44 comes into play.

NAT44 or 444 means you only need small scale UPnP cascaded.

> UPnP is
> not an ISP grade solution, it's a consumer one.

As I said "such as", PCP may be fine. But, recently, I found
several fundamental defects in it, some if which are already
corrected but the discussion is still continuing in its WG.

Masataka Ohta

On Fri, 17 Feb 2012 10:11:22 +0900, Masataka Ohta said:

> While NAT breaks the end to end connectivity, it can be
> restored by end systems by reversing translations by NAT,
> if proper information on the translations are obtained
> through some protocol such as UPnP.

You got a front end NAT. You got 3 boxes behind it that all
want to listen for inbound connections on port 49734.

Let me know how that works out for you.

Valdis.Kletnieks@vt.edu wrote:

>> While NAT breaks the end to end connectivity, it can be
>> restored by end systems by reversing translations by NAT,
>> if proper information on the translations are obtained
>> through some protocol such as UPnP.
>
> You got a front end NAT. You got 3 boxes behind it that all
> want to listen for inbound connections on port 49734.
>
> Let me know how that works out for you.

It's just like your box can't listen for inbound connections
at address 131.112.32.132 (address of my box).

However, if UPnP box is configured properly, your box behind
it can listen for inbound connections on some ports at some
public address.

Issues on stability and advertisements of the port numbers
are not very different from those of addresses, which may
be assigned by DHCP.

Masataka Ohta

End user devices will not benefit from end-to-end connectivity (e.g.,
globally routeable IPv4 addresses as opposed to being in a RFC1918
space behind NAT).

If I have a wildcard DNS record, *.example.edu AAAA 2001:db8::5, then
adding in an explicit record, x.example.edu AAAA 2001:db8::5, will
make no visible difference.

There is no legitimate reason for a user to use BitTorrent (someone
will probably disagree with this).

Our organization is not running out of IPv4 addresses so we don't need
IPv6. (Similarly: Our orginization is running out of IPv4 addresses so
that's why we need IPv6.)

I can't use IPv6 because I still need to serve IPv4 clients.

Any IP that starts with 192 is a private IP and any IP that starts
with 169 is a self-assigned.

Authentication by client IP address alone is sufficient.

Long passwords requiring letters, numbers, and symbols with a
no-repeat policy and a 90-day maximum password age are very secure.

+1 for "We should drop all ICMP(v6) traffic." (Related: "I can't ping
the box so it must be down.")

+1 for "NAT is security".

Regarding "DNS only uses UDP", I give out a technical test during
interviews and one of the questions is basically "Use iptables to
block incoming DNS traffic" and all applicants so far have only
blocked UDP port 53.

On Feb 16, 2012, at 5:11 PM, Masataka Ohta wrote:

> Andreas Echavez wrote:
>
>> *Why disabling ICMP doesn't increase security and only hurts the web* *(path
>> MTU discovery, diagnostics)
>
> That PMTUD works is a misconception.
>

It actually works where people have not made active efforts to break it.

>> *How NAT breaks end-to-end connectivity (fun one..., took me
>> hours to explain to an old boss why doing NAT at the ISP level
>> was horrendously wrong)
>
> That's another misconception.
>
> While NAT breaks the end to end connectivity, it can be
> restored by end systems by reversing translations by NAT,
> if proper information on the translations are obtained
> through some protocol such as UPnP.
>

Sigh... NAT is a horrible hack that served us all too well in address conservation. Beyond that, it is merely a source of pain.

Owen

On Fri, 17 Feb 2012 11:07:59 +0900, Masataka Ohta said:
> Valdis.Kletnieks@vt.edu wrote:
>
> >> While NAT breaks the end to end connectivity, it can be
> >> restored by end systems by reversing translations by NAT,
> >> if proper information on the translations are obtained
> >> through some protocol such as UPnP.
> >
> > You got a front end NAT. You got 3 boxes behind it that all
> > want to listen for inbound connections on port 49734.
> >
> > Let me know how that works out for you.
>
> It's just like your box can't listen for inbound connections
> at address 131.112.32.132 (address of my box).
>
> However, if UPnP box is configured properly, your box behind
> it can listen for inbound connections on some ports at some
> public address.

No, you said specifcially that it can be restored by end system*S*
plural. Yes, I can get one box listening. Now tell me how to get
the second and third boxes listening on the same port. If you can't
do that, then in fact, it is *not* possible to restore *full* end-to-end
connectivity.

> -----Original Message-----
> From: Owen DeLong
> Sent: Thursday, February 16, 2012 8:48 PM
> To: Masataka Ohta
> Cc: nanog@nanog.org
> Subject: Re: Common operational misconceptions
>
>
> On Feb 16, 2012, at 5:11 PM, Masataka Ohta wrote:
>
> > Andreas Echavez wrote:
> >
> >> *Why disabling ICMP doesn't increase security and only hurts the
> web*
> >> *(path MTU discovery, diagnostics)
> >
> > That PMTUD works is a misconception.
> >
>
> It actually works where people have not made active efforts to break
> it.

Modern (RFC 4821) PMTUD that is used by default by Solaris and Microsoft does not require ICMP and works well. For Linux you have to enable it:

/proc/sys/net/ipv4/tcp_mtu_probing = 1 or 2 (I believe the default is still 0 which means it relies on ICMP for PMTUD by default and you must turn on RFC 4821 PMTUD). If you're relying on ICMP for PMTUD, still, then yeah, you probably run into problems from time to time but fewer stacks use that method of PMTUD these days.

Valdis.Kletnieks@vt.edu wrote:

> No, you said specifcially that it can be restored by end system*S*
> plural.

Yes, end to end connectivity is restored.

However, that end to end connectivity is restored does not
mean your boxes can use 131.112.32.132 nor port 49734.

> Yes, I can get one box listening. Now tell me how to get
> the second and third boxes listening on the same port.

Perhaps, you misunderstand how end systems behind NAT
must interact with UPnP or something like that to be
able to restore the end to end connectivity.

End systems behind UPnP boxes are allocated disjoint
sets of global port numbers, only among which, end
systems can use as their global port numbers.

End systems can obtain information on port numbers
they can use through UPnP or something like that.

Thus, there is no port number collision at the global
side of the UPnP box.

Similar mechanism is described in draft-ohta-e2e-nat-00.txt

Masataka Ohta

On Feb 16, 2012, at 18:08, Jack Bates wrote:

> It at first started with trying to explain that vlan based switching is not Layer-3. :(

Ah, one of the greatest misconceptions still around in 2012:

-- OSI Layer numbers mean something.
or
-- Somewhere in the sky, there is an exact definition of what is layer 2, layer 3, layer 4, layer 5 (!), layer 7
or
-- my definition is righter than yours

Grüße, Carsten

On Feb 16, 2012, at 23:41, Michael Sinatra wrote:

> Use of the word "IP" alone to mean "IP address," e.g.:
>
> Person: "Does that server have an IP assigned?"
> Me: "Yeah, it's got a whole stack."

Yeah, and
P: "Can you give me your email?"
M: "All 20 GB of it?"

Grüße, Carsten

I believe he understands just fine. However, his point (and I agree with him) is that
if you are behind NAT, it isn't full end-to-end functionality, even if it does allow some
degraded form of end-to-end connectivity with significant limitations which are not
present in the absence of NAT.

"I can't use your address" is inherent in the network.
"I can't use whatever port number I want on my side of the connection" is not.

Owen

On Feb 16, 2012, at 10:24 PM, Masataka Ohta wrote:

> Valdis.Kletnieks@vt.edu wrote:
>
>> No, you said specifcially that it can be restored by end system*S*
>> plural.
>
> Yes, end to end connectivity is restored.
>
> However, that end to end connectivity is restored does not
> mean your boxes can use 131.112.32.132 nor port 49734.
>
>> Yes, I can get one box listening. Now tell me how to get
>> the second and third boxes listening on the same port.
>
> Perhaps, you misunderstand how end systems behind NAT
> must interact with UPnP or something like that to be
> able to restore the end to end connectivity.
>
> End systems behind UPnP boxes are allocated disjoint
> sets of global port numbers, only among which, end
> systems can use as their global port numbers.
>
> End systems can obtain information on port numbers
> they can use through UPnP or something like that.
>
> Thus, there is no port number collision at the global
> side of the UPnP box.
>
> Similar mechanism is described in draft-ohta-e2e-nat-00.txt
>
> Masataka Ohta

On 2/16/2012 8:30 PM, Carsten Bormann wrote:
> On Feb 16, 2012, at 18:08, Jack Bates wrote:
>
>> It at first started with trying to explain that vlan based switching is not Layer-3. :(
> Ah, one of the greatest misconceptions still around in 2012:
>
> -- OSI Layer numbers mean something.
> or
> -- Somewhere in the sky, there is an exact definition of what is layer 2, layer 3, layer 4, layer 5 (!), layer 7
> or
> -- my definition is righter than yours
>
At the same time, it's shocking how many network people I come across
with no real grasp of even what OSI means by each layer, even if it's
only in theory. Just having a grasp of that makes all the world of
difference when it comes to troubleshooting. Start at layer 1 and work
upwards (unless you're able to make appropriate intuitive leaps.) Is it
physically connected? Are the link lights flashing? Can traffic route to
it, etc. etc.

Paul

George Bonser wrote:

> Modern (RFC 4821) PMTUD that is used by default by
> Solaris and Microsoft does not require ICMP and
> works well. For Linux you have to enable it:

It depends on how you define "work well".

As the RFC says:

indication of some significantly disruptive event in the network,
such as a router failure or a routing change to a path with a smaller
MTU.

it can not react against PMTU changes very well.

It is seemingly working well means there is not much PMTU
changes, which means we had better assumes some PMTU
(1280B, for example) and use it without PMTUD.

Masataka Ohta

Owen DeLong wrote:

> I believe he understands just fine. However, his point (and I agree with him) is that
> if you are behind NAT, it isn't full end-to-end functionality, even if it does allow some
> degraded form of end-to-end connectivity with significant limitations which are not
> present in the absence of NAT.

I'm not interested in your own definitions on end-to-end
something.

For correct terminologies, you should read Saltzer's
original paper.

As for "in the absence of NAT", RFC3102 may also be helpful
to you.

Abstract

This document examines the general framework of Realm Specific IP
(RSIP). RSIP is intended as a alternative to NAT in which the end-
to-end integrity of packets is maintained.

Masataka Ohta

On Feb 17, 2012, at 07:50, Paul Graydon wrote:

> what OSI means

Yet another common misconception popping up:

-- You can talk about the OSI model in the present tense

(That said -- yes, it is still useful as a set of simple terms for certain combinations of functions.
It is also still useful as a way to calibrate your gut feeling of what is going on in a network.
Just never expect OSI terms to have a precise meaning in today's networks.
1978 is now a third of a century ago...
If you need precision, you need to spell out what you mean in today's terms.)

Grüße, Carsten