Randy,
> > (1) The AUTH chunk comes before the material it authenticates,
> > preventing pipelined computation of the MAC. IPsec experience
> > indicates that this may not be a good design choice. If
> > the alternative of putting the MAC after the data it covers
> > (need another chunk to indicate start of covered data) was
> > considered in the WG, the reason for rejecting it needs
> > to be explained.
>
> There are a couple of issues one runs in to if you attempt
> to put the AUTH chunk at the end or a marker in.. not that we
> could NOT have done such..
>
> Firstly we end up violating a fundamental premise in SCTP that
> control is always first. This of course can be broken but
> we did not want to do that.
I don't think it has to violate that premise. Consider two chunks:
- AUTH-START: Start computing MAC here, includes MAC algorithm
and key selection.
- AUTH-END: Stop computing MAC here, MAC value is in this chunk.
To a first approximation, this is a control/data split with
control coming first.
> Secondly the only alternative I remember us discussing was
> that you would place the auth in a packet then all parts
> of the sctp packet are auth'd. This to me caused a processing
> problem in that you had to be willing to back up. Instead
> with the current scheme, when you see the auth chunk, you
> then auth the rest of the packet.. this then lets you set
> a flag that "yes" auth was done. Then when you have chunks
> that require auth all you have to do is check for the flag
> set.
That's consistent with the two chunk approach above.
> Another alternative I guess would have been to require it
> as the first chunk in the packet... then the current scheme
> would have worked I guess.
The current location at the start of the authenticated chunks
is fine.
> I am also not sure what you mean by "preventing pipelined
> computation of the MAC." thinking about this.. Not all
> data may be auth'd in a packet.
Ok, see above comment about the possibility of two chunks.
> Secondly if I have the
> AUTH afterward then it becomes much more difficult to
> then back track and possibly undo anything that has
> been done. Example
>
> If I had
>
> ----
> Add-ip x
> ----
> auth
> ----
>
> Now if the auth fails, I have to undo:
>
> a) Undo the ADD-IP
> or
> b) postpone doing all actions until I do the auth
> and then reprocess the packet again to pick up the
> other chunks.
In other words, two passes over the data are needed
on receive:
- One pass for AUTH, and
- One pass to process the authenticated chunks.
The win from MAC in trailer instead of header turns out to
be on the send side. Assume a staged implementation where
these two passes are functionally separated (e.g., AUTH is
in acceleration hardware that moves stuff to/from the wire).
On send, this gets the AUTH for cheaper (memory accesses)
than running the second software pass. This probably won't
be seen in software because the computational cost of
HMAC-SHA1 swamps everything else.
On receive, the location doesn't matter much, because if the
MAC is not in the trailer, it's easy to pluck it out of the
AUTH chunk as it goes by and check it against the calculation
that covers the rest of the packet.
> I think overall we picked the best processing method.. we
> have at least 3 implementations of this in stacks already
> and I think more will be at the next inter-op :-D
I'm not going to argue with "rough consensus and running code,"
but I would like the draft to explain why the design is the
way it is.
Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA 01748
+1 (508) 293-7953 FAX: +1 (508) 293-7786
[EMAIL PROTECTED] Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
