Soliman, Hesham wrote:
Having read the whole thread, I can't see any convincing reason
to include the flow label in AH.
=> I guess I've said my 2 cents on this point.
Apart from the arguments already expressed, what do we do if
AH fails because of a changed flow label? We discard the packet
instead of delivering it. Does that improve QOS? I don't *think*
so. On the contrary, it creates a trivial new DoS attack.
=> What do we do if any part of the packet was modified
and AH verification (or ESP for that matter) fails? Of course
the packets gets dropped. This has nothing to do with QoS.
That kind of DoS attack is already possible now and there is
nothing more harmful in including one more field.
Well, it would add a protected field that the MITM can change
without preventing packet delivery. I agree there are others,
but my point was to add to the argument that protecting this
field really achieves nothing.
BTW, a lot of people on this thread (not including Brian's
email above) seem to implicitly
imply that the flow label will be modified without
being put back to its original value. I wonder if
the intention here is to break existing specs or are people
forgetting that we already mandate that such scenario is not
allowed?
Indeed, the flow label operates on an "honesty system."
Brian
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
