On 2/11/2016 10:19 AM, Phillip Hallam-Baker wrote: > On Thu, Feb 11, 2016 at 12:58 PM, Joe Touch <touch@xxxxxxx> 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