On Fri, 30 Jun 2006, Jari Arkko wrote:
6. Comparison of mobility protocols (Dave Thaler, 30 min)
http://www.ietf.org/internet-drafts/draft-thaler-mobility-comparison-01.txt
Goal: Increase awareness of where the different schemes are. Discuss.
I liked the draft, though in places it could have possibly gone a bit
deeper. Maybe it's even more useful for the folks who are not aware
of these already. Some comments below.
substantial
-----------
+-------------------+--------------+-------------+-----------------+
| | MIP6 | SHIM6 | HIP |
+-------------------+--------------+-------------+-----------------+
| Stable addresses | Yes | Assumed | Non-routable |
+-------------------+--------------+-------------+-----------------+
==> I believe MIP6 part is mischaracterization. The whole concept of
MIPv6 HoA stability depends on ... well, the stability of Home
Address. So I'd change "Yes" to "HoA Assumed" or just "Assumed".
For example, you cannot renumber your home address when you have
connections going (a bit similar to SHIM6) and you also have
multihoming redundancy issues (like SHIM6) unless you have PI space.
5. Deployment Considerations
+-------------------+--------------+-------------+-----------------+
| | MIP6 | SHIM6 | HIP |
+-------------------+--------------+-------------+-----------------+
| One-end benefit | Yes | No | No |
+-------------------+--------------+-------------+-----------------+
...
SHIM6 and HIP both require support in both ends before their
benefits can be realized.
==> I think you should go a bit deeper on this. Important question to ask
should be, "What impact does enabling this mechanism at one end have, when
it isn't supported on the other?" For example, in HIP there are extra DNS
requests for new RR with HIP, with fallback to A/AAAA (i.e., extra delay
of at least 1 DNS roundtrip, possibly more when trying to connect to any
non-HIP destination).
Maybe you should add "[One-end] Drawbacks", where the answers might be
something like "MTU decrease", "No", "Extra DNS roundtrips". :-)
...
MIP6 depends on the existence of a MIP6 Home Agent to be deployed.
==> which is assumed to have a stable address...
SHIM6 has no outside dependencies.
==> though there have been some ideas (not sure if those have been
taken up or not, described in the app refer document) to make
reverse+forward DNS lookups to help referral-making, unmodified
applications after break...
HIP depends on the IPsec [IPSEC] protocol for basic operation. It
also depends on the existence of a HIP Rendezvous Server for its
mobility mechanisms.
==> you might also mention how the HIP rendezvous server is discovered (I
personally don't know, but I suspect there may be an issue there..)
SHIM6 also uses a return routability test, plus at least a
verification that the new locator is a locator of the same node (but
does not verify that the control message was actually sent by that
node) using a technique known as Hash-Based Addresses; it also
optionally allows CGAs for more security.
==> it might be worth saying here that the verification requires basically a
RR test (to make sure that the IP address is valid) until the address is
taken to use.
HIP, on the other hand, requires strong cryptographic checks on all
control messages.
==> but does strong crypto (as such) prevent 3rd party bombing and
other attacks? You'll just know (unless you use something like
opportunistic ipsec or BTNS) who did it..
6.2. Data security
HIP requires that IPsec [IPSEC] be used for data, whereas IPsec is
optional for MIP6 and SHIM6.
==> at least at some point using ESP NULL encryption was OK in the HIP
context so while data security support is required, its use is not
mandated.
editorial
-----------
Mobile IPv6 (MIP6), the Level 3 Multihoming Shim Protocol (SHIM6),
==> s/Level/Layer/ :)
originated by someone on the path between the two ends. MIP6 at a
mimum only verifies that control messages were originated by someone
==> s/mimum/minimum/
--
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://www1.ietf.org/mailman/listinfo/int-area
