Subject: RE: AH and flow label

From: [email-masked]
Date: Fri, 10 Sep 2004 17:02:00 -0700 (GMT-07:00)

>Why do you think this is important and what problem does it solve?

This appears to be the key. Maybe I am missing something, but aren't flow labels possibly looked at and used at hops in between the src and dst? If the flow label is changed/hacked along the way, isn't the damage (not going to try and quantify damage here because that really depends on what the hops do based on the value) already done before the destination is in a position to determine if the packet is compromised? If 100% security is desired, then somehow the flow label needs to be verifiable at each hop (in the hop by hop header). Not sure how likely this is.

So while it seems like a good thing to protect this  field in the ICV computation, I am not sure that any value that can be realized is worth the potential of incompatible versions not being able to communicate in a secure way when flow labels are being used. If you do want to change the spec, then maybe another option is needed that tells the DST if the flow label is being included in the ICV or not.

--rich 

thanks
/jim 

> -----Original Message-----
> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Friday, September 10, 2004 12:56 PM
> To: Bound, Jim
> Cc: Francis Dupont; [email-masked]
> Subject: RE: AH and flow label
> 
> At 11:37 AM -0400 9/10/04, Bound, Jim wrote:
> >Francis,
> >
> >The flow label should not be part of the ICV because it is 
> permitted to 
> >be rewritable enroute as long as it is delivered in tact E2E.  I say 
> >keep as it is today.  No other comment.
> >
> >Thanks for asking,
> >/jim
> Jim,
> 
> If it is delivered with the same value as when it was sent, 
> then it can be included in the ICV computation. Note that the 
> requirement for inclusion is that a value either be immutable 
> OR be predictable at the receiver. So, what you indicated 
> above would not be a basis for excluding the flow label.
> 
> Steve
> 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Mon, 13 Sep 2004 16:35:37 -0400

At 5:02 PM -0700 9/10/04, [email-masked] wrote:
>This appears to be the key. Maybe I am missing something, but aren't 
>flow labels possibly looked at and used at hops in between the src 
>and dst? If the flow label is changed/hacked along the way, isn't 
>the damage (not going to try and quantify damage here because that 
>really depends on what the hops do based on the value) already done 
>before the destination is in a position to determine if the packet 
>is compromised? If 100% security is desired, then somehow the flow 
>label needs to be verifiable at each hop (in the hop by hop header). 
>Not sure how likely this is.
>
>So while it seems like a good thing to protect this  field in the 
>ICV computation, I am not sure that any value that can be realized 
>is worth the potential of incompatible versions not being able to 
>communicate in a secure way when flow labels are being used. If you 
>do want to change the spec, then maybe another option is needed that 
>tells the DST if the flow label is being included in the ICV or not.
>
>--rich
>

Rich,

For unicast flows, the commonly employed ICVs are based on symmetric 
key management, and so it is unlikely that intermediate systems would 
be able to verify the ICV.  The MSEC folks have proposed public key 
based ICV mechanisms that do permit verification en route, but these 
are intended for multicast flows.

However, as I noted earlier, there was no stated requirement that the 
old and new versions of AH be interoperable, although they could be, 
in principle, if we did not make this change.

Steve