On 2/11/2016 10:19 AM, Phillip Hallam-Baker wrote:
On Thu, Feb 11, 2016 at 12:58 PM, Joe Touch <touch(_at_)isi(_dot_)edu> wrote:
On 2/11/2016 6:05 AM, Masataka Ohta wrote:
Joe Touch wrote:
I repeat: nodes that encap or decap are acting as sources or sinks, not
relays.
I'm afraid firewalls are relays.
A firewall that filters on L3 is a router regardless of which side you
look at.
Using 'layers' to describe Internet architecture can be very
misleading because the Internet isn't layered according to the ISO
model and the layers don't necessarily stack up the way people expect
once tunneling is involved.
Internet layers correspond to ISO layers up through 4 fairly well.
Layers have always been relative, though - what I think is layer 4 might
be layer 2 to you if you're using my UDP to transit your IP inside.
For example, if I have an SSH channel to a system (or a TLS firewall),
I have a transport layer protocol that is presenting a packet layer
interface.
So if we number the layers, we have 1, 2, 3, 4, 5, 3 [4, 5, 7].
Strictly, you have two different views:
SSH [1, 2, 3, 4, 5] acting as [1* 2*] to the transit protocol.
The complete SSH view is:
[1, 2, 3, 4, 5, 7#] where 7# is the transit
(where the transit acts as an application)
The complete transit view is:
[1*, 2*, 3, 4, 5, 7], where 2* is a tunnel (which *is*
just a link) and 1* is virtual
SSH needs to treat the transit as an application.
The transit needs to treat SSH as a link (including support, if needed,
for ARP, MTU discovery, etc.)
One of the things I learned early on programming Microsoft BASIC was
to not use sequential line numbers. And I was really glad to get rid
of line numbers when I moved to machines with decent amounts of RAM.
Seems to me that the numbered layer model confuses rather than
clarifies and especially so when tunneling is being discussed.
Once you move to tunnels you need to think in relative terms, not absolutes.
A tunnel should be a tunnel.
A tunnel *is* (and always has been) a link.
The only difference between a tunnel and a link is that a link is a
special subset of "all tunnels that run over physical connections".
If you fragment at the tunnel ingress,
you should defragment at the egress. Otherwise you are simply pushing
your state maintenance requirements onto the receiving endpoint in a
way that isn't scaleable.
The beauty of considering a tunnel a link is that the same rules apply,
as they always should have. Just as a link that can't transit an IP
packet requires frag/reassembly within the link (e.g., ATM does this),
so should a tunnel.
Joe