Subject: RE: AH and flow label

From: "Bound, Jim" <[email-masked]>
Date: Fri, 10 Sep 2004 11:38:15 -0400

I would have impact to existing implementations yes it is not part of
the ICV now and should not be.
/jim 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Brian Haberman
> Sent: Friday, September 10, 2004 6:50 AM
> To: Francis Dupont
> Cc: [email-masked]
> 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-masked]
> >
> > 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-masked]>
> > Date: September 9, 2004 14:58:36 EDT
> > To: Francis Dupont <[email-masked]>
> > Cc: [email-masked]
> > 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-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: [email-masked]
Date: Fri, 10 Sep 2004 12:59:58 -0500

> Right.  My question was an attempt to see how many implementations
> support IPSec AH today.

We have one that supports IPsec AH for IPv6 and I am pretty sure
that there are many more :)

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 10 Sep 2004 14:50:19 -0400

Yes and good point see my response to Stephen.
Thanks
/jim 

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Friday, September 10, 2004 1:43 PM
> To: Bound, Jim
> Cc: Francis Dupont; [email-masked]; Stephen Kent
> Subject: RE: AH and flow label
> 
> On Fri, 10 Sep 2004, Bound, Jim wrote:
> > 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.
> 
> But it won't be possible to verify the AH enroute in any case 
> (or are you assuming that those who do the rewriting have the 
> keying material
> -- I'd be surprised to see such deployments), so it would 
> still be rewritable as long as it's reversed.
> 
> This is actually better because it would ensure that the flow 
> label would actually be reversed if rewritten (otherwise, 
> some deployments might be tempted to just rewrite it) because 
> not doing so would fail end-to-end AH.
> 
> But I see the problem with breaking existing implementations 
> (and I don't know how commonplace this is, and don't know the 
> interoperability assumptions), so I don't have strong 
> preference on this either way.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 11 Sep 2004 02:24:23 -0400

Stephen,

Yes it does and that means it is less painful for implementation.  But
still need for it to be compelling.

Thanks
/jim 

> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Friday, September 10, 2004 4:08 PM
> To: Bound, Jim
> Cc: Francis Dupont; Brian Haberman; [email-masked]
> At 2:56 PM -0400 9/10/04, Bound, Jim wrote:
> >OK I am worried now.  Is there a security hole and 
> potentially serious 
> >problem by not including the Flowlabel in the ICV?  We do 
> need to ask 
> >this question and should not ignore it.  Then the trade offs can be 
> >determined.  But that data and what problem it solves should 
> be fairly 
> >compelling to go tell product implementors to add it.
> >
> >Thanks
> >/jim
> >
> 
> Jim,
> 
> Based on your comments in this message, I think there is some 
> misunderstanding.
> 
> We are not talking about changing AH v1; we are discussing AH 
> v2. To correctly implement AH v2, one already has to be able 
> to accommodate
> 64 bit sequence numbers, vs. the 32 bit sequence numbers in 
> v1. AH v2 is still an I-D, not an RFC. So, while a change in 
> whether to include the flow label in the ICV would make v2 
> not backward compatible with v1, v2 is already not backward 
> compatible with v1 due to the required sequence number 
> support difference.
> 
> Does this help?
> 
> Steve
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sat, 11 Sep 2004 02:25:26 -0400

Thanks and good response.  The rationale will be important for product
explanation too.
/jim 

> Sent: Friday, September 10, 2004 3:54 PM
> To: Bound, Jim
> Cc: Francis Dupont; [email-masked]
> At 2:49 PM -0400 9/10/04, Bound, Jim wrote:
> >Agreed and knew that when I sent it.  Sorry.  I think any field that 
> >can be legitmately altered by a standard set of 
> interoperablity specs 
> >should not be in the ICV.  I can see the add value of authenticating 
> >the flow label but I have concerns over the benefit of that and 
> >performance and change to the implementations.
> >
> >Why do you think this is important and what problem does it solve?
> >
> >thanks
> >/jim
> 
> I don't necessarily think it is important, but we either have 
> to change the processing description or change the rationale 
> for why we omit it from the ICV, since the current rationale is wrong.
> 
> BTW, I don't think there would be a noticeable performance 
> issue if it were included.  Unfortunately, AH is slow because 
> of the need to skip over selected fields already, so this is 
> adding to that pain, but probably not by much :-)
> 
> Steve
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 Sep 2004 00:29:23 -0400

Hesham,

It sounds to me this brings no real value to IPsec.  You must be seeing
something I don't could you please state why your so supportive for this
change and what are your technical reasons that will add value for IPv6?

Thanks
/jim 

> Behalf Of Soliman, Hesham
> Sent: Saturday, September 11, 2004 8:04 PM
> To: [email-masked]
> Cc: Brian Haberman; [email-masked]
>    I agree with the drawback you see and it's not ideal.
>    But I also think the whole flow label story was inconsistent
>    and we finally have concensus on how we want to use it. 
> 
> > => this is something we should not reproach the ipsec WG for...
> 
> => I wasn't reproaching the IPsec WG. Please don't put words 
> in my mouth or email!
> 
>    Given the fact that it is immutable, it makes a lot of 
>    sense to protect it. 
>    
> >=> this is a "make it prettier" weak argument, i.e., we have 
> to assume 
> >our previous inconsistencies.
> 
> => What is the counter argument?? Stephen Kent already 
> mentioned that this is not a change to the older version of 
> AH. So if all the benefit you can see is that it makes things 
> "prettier"
> and consistent then why not??
> 
>    The benefit depends on the application. In cases where 
>    the value of the flow label is used for any type of decision
>    making related to routing or QoS (in an end host) it is very
>    important to make sure that it was not modified by MITM. 
>    Today there is no way of knowing this. 
>    
> >=> as only the destination can check the ICV, the 
> application must both 
> >be at the destination, not on an intermediate node, and need a per 
> >packet protection of the flow label. I don't know such 
> application, in 
> >fact in general there is even no API to get the received flow label!
> 
> => That doesn't mean it can't happen. There was no API to 
> support v6 a few years ago. We can enable this feature and it 
> can be used by anyone in future. 
> 
> 
>    I have several ideas in mind for using the flow label.
> 
> >=> many of us have, but not one implying the usage of AH.
> 
> => Francis, I'm sure you know that if anyone tries to 
> standardise a mechanism that uses the flow label e2e and 
> requires it to be secure IPsec is the only way to do it. Do 
> you have other alternatives? 
> 
> >In fact the last time AH was nearly deprecated we didn't find 
> >convincing cases where the extra protection provided by AH 
> was really 
> >an advantage...
> 
> => I didn't follow those arguments and AH is obviously not 
> deprecated so it makes sense to keep things consistent in standards.
> 
>    One of those was published in the flow movement draft. So
>    if the above is too abstract please see 
> draft-soliman-mobileip-flow-move
>    for an example. 
>    
> >=> I've looked at the (expired) document: there is no security 
> >considerations so no recommendation to use AH. And when I 
> try to build 
> >an argument I get two cases:
>  - end-to-end flow movement (i.e., with routing 
> optimization): the classic
>    5-tuple works and is even better because for instance it 
> supports wirdcards.
> 
> => The flow label option saves more bits over the air, which 
> is quite important for wireless networks. 
> 
> Hesham
> 
> ===========================================================
> 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.
> ===========================================================
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 Sep 2004 13:11:55 -0400

Excellent, Excellent point. Thanks Christian.  Hello folks :--)
/jim 

> Behalf Of Christian Huitema
> Sent: Sunday, September 12, 2004 12:30 PM
> To: Francis Dupont; Soliman, Hesham
> The suggestions of making the flow label immutable and 
> protecting it by AH look like bad ideas. The 20 bits in the 
> "flow label" are the only reserved bits in the header. These 
> bits should be available for future innovation. If we make 
> them strictly immutable, how will we able to create something 
> like ECN in the future?
> 
> -- Christian Huitema
>

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 13 Sep 2004 10:53:33 -0400

Christian, 

This discussion is not really in line with existing 
specs. We already have a spec that says the flow label
is immutable e2e. Revisiting this is a different story.
We're talking about existing specs.

Hesham

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Sunday, September 12, 2004 12:30 PM
To: Francis Dupont; Soliman, Hesham
Cc: Brian Haberman; [email-masked]
Subject: RE: AH and flow label 

The suggestions of making the flow label immutable and protecting it by
AH look like bad ideas. The 20 bits in the "flow label" are the only
reserved bits in the header. These bits should be available for future
innovation. If we make them strictly immutable, how will we able to
create something like ECN in the future?

-- Christian Huitema

===========================================================
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.
===========================================================

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 13 Sep 2004 15:46:50 -0400

> From: Soliman, Hesham [mailto:[email-masked]]

> 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?  

Perhaps this happens because RFC 2402 says that the IPv6 flow label is mutable (in para. 3.3.3.1.2.1). But RFC 2460 seems to disagree in terms of current use (as of 1998), in Appendix A, even though in Section 6 the words allow for any sort of change in the future use of this field ("subject to change").

However, if this flow label is to be included in the ICV, as long as the flow label is returned to its original value before header verification at the destination side (be it tunnel or transport mode), all should be fine.

Unless the wg has resolved that the flow label is absolutely *not* still "subject to change," what's the urgency to get it included in the ICV? Are we lacking for fields included in the ICV? Do we just need words to justify its non-inclusion?

Bert

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 13 Sep 2004 16:12:50 -0400

Ok, please see RFC 3697 for the latest document on the 
flow label. This reflects current concensus.

Hesham

-----Original Message-----
From: Manfredi, Albert E [mailto:[email-masked]]
Sent: Monday, September 13, 2004 3:47 PM
To: Soliman, Hesham
Cc: [email-masked]
Subject: RE: AH and flow label

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 13 Sep 2004 17:53:41 -0400

In the context of RFC 3697, it seems to me that there can only be one AH-related difference if the flow label is included in the ICV:

If the flow label is included in the ICV, then a theft of service attack will result in a complete loss of communication between source and destination(s). If the flow label is not included in the ICV, then a theft of service attack will result in possibly lower QoS (in a benign situation), but not necessarily complete loss of communications, unless the theft of service attack becomes a denial of service attack.

As the RFC states, anyone capable of spoofing the flow label can also spoof the addresses (which are definitely included in the ICV), so it's not entirely clear to me whether inclusion of the flow label in the ICV computation is desirable or not, in AH. Maybe it's a toss-up?

Non-inclusion of the flow label in the ICV computation allows for a sort of higher granularity theft of service attack. Rather than all or nothing, it allows an attacker to tweak the QoS, potentially.

To actually protect an e2e flow with QoS, you would probably need to use ESP to protect some or all of the hop by hop routing options. That would drive the protected QoS packets along a specified, protected route that a hacker would presumably not know, and therefore would have a harder time hacking.

Bert

> Perhaps this happens because RFC 2402 says that the IPv6 flow 
> label is mutable (in para. 3.3.3.1.2.1). But RFC 2460 seems 
> to disagree in terms of current use (as of 1998), in Appendix 
> A, even though in Section 6 the words allow for any sort of 
> change in the future use of this field ("subject to change").
> 
> However, if this flow label is to be included in the ICV, as 
> long as the flow label is returned to its original value 
> before header verification at the destination side (be it 
> tunnel or transport mode), all should be fine.
> 
> Unless the wg has resolved that the flow label is absolutely 
> *not* still "subject to change," what's the urgency to get it 
> included in the ICV? Are we lacking for fields included in 
> the ICV? Do we just need words to justify its non-inclusion?
> 
> Bert

---

From: [email-masked]
Date: Mon, 13 Sep 2004 19:41:22 -0400 (EDT)

>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.

Thanks for the response and explanation. I guess in my earlier email I was getting what you just said. There is no way for intermediate systems to verify the ICV so if the flow label is hacked along the way it will not be detected until the end system verifies the ICV, which may be too late to stop whatever damage has happened. (I think someone else subsequently posted a similar analysis as well). Since the ICV is not going to protect guard against such problems, its inclusion in the ICV is really not going to buy us anything.

If people think that including the flow label in the ICV is important, then I think what is being said is we need to know if the flow label is being maliciously changed inflight. If this is the case, then the ICV is not sufficient and we need an hop-by-hop solution.

>Steve

--rich

---

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 13 Sep 2004 22:23:11 -0400

=> That's because you are assuming that the flow label can only
be used for QoS related applications. Even if we go with this 
assumption, if a real time app gets treated as a best effort
app then effectively there is no real time communication. 

=>BTW, if someone is able to modify the header and wants to deny
all communication for a node, I have another way to do it, change
either address in the header! You don't need the flow label to do
that...

Hesham

Bert

---

From: [email-masked]
Date: Tue, 14 Sep 2004 07:03:58 +0300

Hi all,

> Having read the whole thread, I can't see any convincing reason
> to include the flow label in AH.

I basically agree with Brian here. Most of the reasons seem to be 
centered around possible new uses of the flow label, but without
having consensus on these new proposals, it seems like a bad idea
to break existing implementations.

John