Hi Pekka, I have some precisions on HIP inlined below,
[...] > 5. Deployment Considerations > 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). I don't think that is necessarily the case. The HIP DNS draft has no normative text describing that lookups should be serialized and ordered. It is entirely possible that you issue simultaneously A/AAAA and HIP RR QUERIES (and I was told my DNSext people that it's not a problem.) If you receive a HIP RR the other end does support HIP and you establish an association, and if no HIP RR comes back you connect with plain IP. [...] > 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..) A MN's rendezvous server information would typically be stored in the DNS using the HIP RR. This is similar to storing MIPv6 HA IP address in the DNS. > 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.. HIP also has address reachability checks which prevents 3rd party bombings. > 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. HIP as mandatory support for ESP NULL encryption with HMAC-SHA1 integrity. Best, --julien _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
