On Fri, 18 Jul 2008, Joe Touch wrote:
|> These sound okay but I would like to see "tunnels" split into two: one
|> type where there is a setup phase and sharing state between the
|> endpoints, and another where there is no shared state: an endpoint can
|> encapsulate a packet, toss it to another endpoint, and the receiving
|> endpoint will decapsulate it and do the right thing. There are three
|> qualitatively different levels in the setup mechanism and where shared
|> state resides.
...
| So, I'm afraid this would be like trying to characterize something as
| black and white, where in reality there are shades of gray.
There are basically known variations of state; these aren't new to tunnels:
- preshared, static
- negotiated, hard
- negotiated, soft
I'm not sure if this falls under "preshared, static", but 6to4 (RFC
3056) uses a mapping technique to discern the endpoint. I can't find
any form of state anywhere in that tunneling mechanism.
Another dimension is who is involved in state coordination:
- third party informs both ends (dual push)
- third party triggers one end, and that end coordinates
with the other end (push, negotiate)
- third party triggers one end, and the other end fetches
state when needed (push/pull)
The last bullet might include this scenario but IMHO it should be a
bullet item of its own:
As an example, in RFC 4023 (MPLS in GRE or IP), one way to decapsulate
said packets was to just take everything you get at input, strip the
headers, and forward packets out. Some state (e.g., communicated
using BGP, LDP, or some other protocol) is needed at the encapsulating
router. Decapsulating router requires no state whatsoever. Where
does this belong?
Interesting questions to ask wrt. each tunneling technique are at
least:
- does this require state at the decapsulator? If so, what?
- what are the security implications of state maintenance or lack
thereof?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
