I also agree.
jak
----- Original Message -----
From: "Soliman, Hesham" <[EMAIL PROTECTED]>
To: "Brian Haberman" <[EMAIL PROTECTED]>; "Francis Dupont"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, September 10, 2004 7:41 AM
Subject: RE: AH and flow label
I agree with Brian. I'd like to see it protected.
Hesham
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Brian Haberman
Sent: Friday, September 10, 2004 6:50 AM
To: Francis Dupont
Cc: [EMAIL PROTECTED]
Subject: Re: AH and flow label
Speaking as an IPv6 wg member, I am not comfortable with the flow label
being
unprotected. As an immutable field, it should be included in the ICV
calculation.
I have seen several projects started that intend on taking advantage of
RFC 3697.
My main question is how much of an impact would such a change have on
the existing IPv6 implementations.
Can anyone speak to their IPv6/IPSec implementations on this issue?
Regards,
Brian
On Sep 10, 2004, at 4:49, Francis Dupont wrote:
> Here is a message from Steve Kent who is updating the RFC 2402
> "IP Authentication Header (AH)" about the flow label status.
> I have put it in this list for people interested by IPsec but
> who have no enough time to read the mailing list...
> To summary the question is:
>
> Is the [ipsec] WG comfortable with the status quo, i.e., NOT including
> the
> flow label in the ICV [integrity check value], despite the fact that it
> is immutable?
>
> [EMAIL PROTECTED]
>
> PS: of course my opinion is we have to keep the status quo and
> the decision is in the scope (i.e., hands?) of the ipv6 WG.
>
> From: Stephen Kent <[EMAIL PROTECTED]>
> Date: September 9, 2004 14:58:36 EDT
> To: Francis Dupont <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2402bis-07.txt ... Suggest
> moving the "Flow Label" IPv6 base header field to "immutable" and
> protecting with AH
>
>
> Francis,
>
> I looked at RFC 3697. It does state that AH does not protect flow
> labels, which is consistent with the old AH spec (RFC 2402). So, if we
> were to change this in the new AH spec, there would be a conflict.
> Also, the security analysis in 3697 argues that since there is no
> protection of the flow spec value, intermediate systems cannot rely on
> it and an end IPsec implementation cannot rely on it in transport
> mode. I agree that it is unlikely that we would be able to manage key
> distribution for intermediate systems to be able to check the AH ICV,
> which supports your argument that it is not worth including it in the
> ICV computation.
> However, if we choose to maintain backward compatibility with 2402, we
> need to clarify in 2402bis that this is the reason for not including
> the value in the ICV computation, as opposed to the current, erroneous
> rationale.
>
> Is the WG comfortable with the status quo, i.e., NOT including the
> flow label in the ICV, despite the fact that it is immutable?
>
> Steve
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [EMAIL PROTECTED]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
===========================================================
This email may contain confidential and privileged material for the sole use
of the intended recipient. Any review or distribution by others is
strictly
prohibited. If you are not the intended recipient please contact the
sender
and delete all copies.
===========================================================
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
