[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: notes from developer's portion of IETF meeting
Sorry that you couldn't be there Steve, as the implementors meeting was
the most useful of any IPSec meeting in recent memory. But, part of the
problem seems to be that the "notes" sent to the list don't quite match
my understanding of the decisions reached, and have little of the
rationale that was voiced in the meeting. I thought that someone else
was taking notes; could they send their writeup, instead?
In my view, the result was that we have _finally_ returned to the packet
formats and functionality agreed in Amsterdam in July 1993. We have come
full circle.
> From: Stephen Kent <kent@bbn.com>
> Use of AH is not the same as use of ESP w/o encryption, precisely because
> of the coverage issue, and the associated performance hit.
(analysis omitted)
> What I'm
> hearing from this discussion is that the motivation for not offering ESP
> w/o encryption is added complexity. I'm all in favor of reducing
> complexity, if it doesn't cost functionality, but I'm really surprized to
> hear that offering ESP w/o encryption is percieved as a significant
> increase in complexity.
>
The verbal rationale that I remember was that the main use of AH would
be for the tunnelling gateways that Moskowitz diagrammed, where you need
to authenticate the IP addresses of the routers. This keeps the tunnel
down to a single tunnel across the net. I remember Richardson giving us
the same (single tunnel level) recommendation over a year ago.
The orthogonal use of AH provides function that would not be available
with ESP alone.
And, it _also_ reduces complexity in implementation of ESP. You are
correct, the implementors seemed quite taken with that idea.... :-)
No rationale was given for the practical need for authentication-only
ESP, and thus it was not chosen as an option. Is there any reason other
than the minor performance gain that you mention, that cannot be handled
by AH as it stands?
> I assume you meat to say that ESP with authentication was useless, but I
> have to disagree. I know folks who are sending packet voice and packet
> video on an end-to-end basis. I recommend use of ESP w/o authentication in
> this context.
Here, the notes are simply wrong (by omission). The group agreed that
ESP encryption without integrity needs an external AH _only_ where
required for security!
You are correct, and was elaborated by Bellovin's paper long ago, there
are many instances where extra authentication for integrity is not
required.
As I recall, integrity is required for security _only_ when there are
mutually hostile users on multi-user systems at both ends of the
connection/path. These multi-user systems "know" that they require
integrity, and can negotiate it appropriately.
OTOH, a dialup user encrypting to a firewall (or even their target
multi-user host) from a laptop would _not_ require added integrity. Big
interactive RTT savings on a low speed link.
> However, per-packet overhead is a big
> concern here and thus stripping out everyting but the encryption support is
> an important feature. Thus the flexibility offered by modular use of ESP
> and AH is important to these folks and is in keeping with the original
> intent of IPSEC.
>
Could you put that in the architecture for posterity?
> I think the better argument is that AR counter inclusion makes alignment
> "work" for AH in the IPv6 context, and in ESP this inclusion aligns the
> start of the payload (assuming that we fold the IV into the payload) on an
> 8-byte boundary as well, to facilitate crypto processing. Also, by always
> sending this field, one simplifies packet parsing, by eliminating
> variability. If these are the reasons for mandating inclusion of the AR
> counter in every AH and ESP packet, then so be it, but at least lets agree
> on a rationale that makes it clear what tradeoffs were considered in coming
> to this conclusion.
>
Could you cite all of the above in the architecture for posterity?
I will note that there were questions raised by several in the room
about mandating the field in AH, as this would be a change in bits on
the wire for older implementations. Perhaps someone could post their
arguments here for the rest of the group.
I don't think we had agreement on AH. Just ESP.
> In general I propose that we remove the
> IV as an explcit, optional field and fold it into the beginning of the
> payload. The text will be modified to state this convention, noting that
> each algorithm document must state the presence/absence of an IV (or a
> sequence space pointer for some types of stream ciphers) and the size of
> the IV. That way we can keep the ESP document simple and algorithm
> independent.
>
Yes, that was my understanding of the agreement; please put that
rationale in the ESP document.
WSimpson@UMich.edu
Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: