-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Pekka Savola wrote:
...
|> 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.
The "state" is sharing the mapping algorithm; that's effectively an
on-demand computed table that both ends share.
|> 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?
"decaps everything" is never quite that; it only decapsulates things
with the appropriate header sequence. Again, this is like shared static
state where both ends know that the receiver will be doing this.
| Interesting questions to ask wrt. each tunneling technique are at least:
| - does this require state at the decapsulator? If so, what?
IMO, they always require state at both ends, even if the state is
encoded in algorithms like "encaps all" or "decaps all with X as an
outer header".
| - what are the security implications of state maintenance or lack
thereof?
Absolutely! We haven't touched on many aspects of shared state, including:
- - in vs. out of band coordination (when coordinated)
- - security
- security of that coordination
- security of the resulting tunnel mechanism
e.g., can an intruder overload the state
- security of packets through the tunnel
This is, as noted, a preliminary version of the doc, and other
suggestions for missing items would be great!
Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiEpZkACgkQE5f5cImnZrsGPQCfc1ElYwrS5QVe3Htp1TntbA0g
A0cAn2/7HNoYVeyzdil1jmOwPXHt/SIA
=WZFt
-----END PGP SIGNATURE-----
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
