[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Evaluation: draft-ietf-mobileip-mipv6-ha-ipsec - Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents to Proposed Standard
- To: IESG Secretary <iesg-secretary@ietf.org>
- Subject: Re: Evaluation: draft-ietf-mobileip-mipv6-ha-ipsec - Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents to Proposed Standard
- From: "Steven M. Bellovin" <smb@research.att.com>
- Date: Thu, 10 Apr 2003 21:34:30 -0400
- Cc: Internet Engineering Steering Group <iesg@ietf.org>
In message <200303290155.UAA28438@ietf.org>, IESG Secretary writes:
>
>Last Call to expire on: 2003-3-7
>
> Please return the full line with your position.
>
> Yes No-Objection Discuss * Abstain
>
>
>Allison Mankin [ ] [ ] [ X ] [ ]
Per Steve Kent's comments (see his annotated version of the draft
at http://psg.com/~smb/draft-ietf-mobileip-mipv6-ha-ip.htm ),
there seems to be a serious mismatch between the semantics of IPsec and
what is needed by this spec. In particular, the spec demands special
matching and processing rules for input and output packets that are
seriously inconsistent with IPsec. In principle, IPsec might be
changeable in this regard, since the specs are currently undergoing
revision; in practice, I suspect that the changes needed are too great.
In any event, the changes will require the approval of the IPsec
working group.
Beyond that, this spec requires changes to the SPD as the mobile node
roams. That implies a deep coupling between the MobileIP layer and the
IPsec layer. Implementation might be problematic if outboard (i.e.,
NIC-resident) IPsec implementations are used. I would note that these
have been on the market for a couple of years at the least; they're not
hypothetical devices. I suspect that some of these issues might be
resolvable by using IKE and negotiating new Phase 2 associations. This
would rely on the existing API to IPsec, though admittedly it might
require a new interface to IKE.
Kent's much more detailed comments must be addressed, too.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)