[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC AH -- document
Steve,
> Yes, I meant exit! And yes, we agree that a suitably high level
> BITS IPsec could deal with the problem, but a device driver level
> implementation would have difficulties. The major motivation for BITS
> implementations is backward compatability, as you noted, so relying on
> hooks in the IP implementation seems questionable. Still, I think we agree
Agreed. Yes, a single-interface-only driver wouldn't solve the
multi-interface reassembly problem. However, the "hooks" I was
thinking only of in conjunction with BITW interface cards (not a "just
under IP" BITS) and I sure didn't feel comfortable with that idea. Its
worse than "questionable", its something that might make sense on some
specific platform though one would wonder if it wasn't easier to just
update the whole stack at that point or effectively have an "under IP"
BITS extension anyway. I intended to show how much more difficulty a
BITW would have, even if it was as close as an interface card (I guess
I see why you might call that a BITS instead), than an "under IP" BITS
in dealing with the multi-interface fragmentation issues. Also I
didn't want, even in *that* ugly situation, to rule out the possibility
that some clever BITW vendor may think of something we hadn't in order
to support Transport mode in (some?) multi-interface machines.
Sorry for any confusion, lets drop this bad "hook" suggestion I had.
> that a warning to implementors about the subtilties of BITS and BITW
> transport mode is OK, just so long as we don't suggest that such
> implementation ought not support this mode. I have already modified the
Good.
> text in the AH and ESP I-Ds to accommodate suhc wording, but mayeb moving
> it to the arch document is preferable (as it is a common problem). I'm
> flexible.
Either way sounds good to me. From my point of view you could leave it where
you've now got it, in the interest of saving time.
-- Marc --
Follow-Ups: