Re: [Mip4] AD review comments on advance draft-ietf-mobileip-lowlatency-handoffs-v4-08.txt

["James Kempf" <[e-mail]>]

Pete,

> Security considerations needs work. At a minimum, the text about "use
> ESP" seems insufficient (see security AD comments in ID tracke for
> draft-ietf-seamoby-card-protocol for starters - I suspect the same
> point applies to this document.) THe security analysis as a whole
> seems pretty weak, and in reading it, I didn't get a sense that the
> security issues were well-understood. E.g., seems like a lot of the
> security properties depend on L2 security, of which there is no
> discussion. I.e., has a detailed analysis in the context of a specific
> LL type  been done? Could it be done?
>

The CARD draft was recently rewritten to use SEND signatures based on the
SEND router certificates, as suggested by Steve Bellovin in the comments
Thomas refers to here. The Seamoby WG is still in the process of discussing
a few final comments about the document, but since CARD applies to IPv4 as
well as IPv6, a similar solution might apply here (of course, the rewritten
draft has not yet been through the IESG so there may yet be suprises in
store for the Seamoby WG). The new CARD security protocol drops IPsec for
the MN-AR interface and instead uses the SEND security association (IPsec
remains for the AR-AR interface, however).

One major issue is certificate exchange. In IPv6, the SEND DCS/DCA messages
can be used for certificate exchange on the same router, but there's nothing
like that for IPv4, even if the same signature format and certificate
profile as SEND is used. The solution for CARD is to define a certificate
exchange extension that works similarly to SEND, with the MN sending a list
of trusted roots and the AR sending back the chain for one of them. An
additional benefit that CARD provides is that the MN can solicit for
certificates to handover candidate access routers connected to APs that the
MN can see, thereby allowing the MN to have the certificate chain
preconfigured for the new AR prior to movement. This can result in
additional latency reduction for handover.

Provided the MIP4 WG was willing to go with CARD certificate exchange, the
SEND signature option could be reused for low latency handover PrxyRtXXX
messages as was done for CARD. The alternative option would be to try
defining something like DCS/DCA for IPv4, but there is little realistic
chance that it would be deployed, since AFAICT, hosts in IPv4 rarely use
router advertisments to discover their default routers, they use DHCP. The
exception is Mobile IPv4 FAAdverts, of course.

An alternative would be to reuse the MIPv4 MN-FA authentication extension
for low latency. If the WG decides that it likes that alternative better, it
might be a good idea to talk to Steve Bellovin and Russ Hously about it
first, to make sure they are OK with it, to avoid another IESG return.
While the SEND solution looks like a pretty good one from a technical
standpoint for this problem, the assumption is that Steve preferred that
solution since he explicitly mentioned it in his comments, which is
secondarily why it was used in CARD.

            jak





-- 
Mip4 mailing list: [e-mail]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/