st way to protect a flow where the Flow Spec value really matters is to use ESP and send the critical traffic through a tunnel.
Bert
-Original Message-
From: timothy enos [mailto:[EMAIL PROTECTED]
Sent: Friday, October 08, 2004 12:35 AM
To: [EMAIL PROTECTED]
Subject: RE: AH and flow
Title: RE: AH and flow label
I believe I had the last
word on this thread until today.
The original version of
AH, RFC 2402, has the Flow Spec value as being mutable.
RFC 2460, IPv6
spec, has the Flow Spec value potentially mutable.
Diffserv, RFC 2475, has
the DS codepoint as being
In your previous mail you wrote:
Good morning. Having been away from the list for a while, it's not clear
to me what (if any) the consensus (and subsequent decision) is regarding
inclusion of the IPv6 Flow Label field in the AH ICV. If consensus and a
decision were reached, what were/
Title: RE: AH and flow label
Good morning. Having been away from the list for a while, it's not clear to me what (if any) the consensus (and subsequent decision) is regarding inclusion of the IPv6 Flow Label field in the AH ICV. If consensus and a decision were reached, what were/are
Manfredi, Albert E wrote:
Perhaps the reason given in RFC 2402bis should be simply stated. The flow label described in AH v1 was mutable, and in RFC 2460 was potentially mutable. To retain compatibility with existing AH implementations, the flow label is not included in the ICV in AH v2.
Sounds goo
> Note that
> the current text MUST be changed, as it gives the wrong reason for
> not including the flow label under the ICV. So, we either change the
> rationale provided, or we change how we handle the field. All I was
> asking was which of these would folks prefer.
>
> Steve
Perhaps the r
At 12:39 PM +0300 9/13/04, Jari Arkko wrote:
Steve,
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, whi
At 5:02 PM -0700 9/10/04, [EMAIL PROTECTED] wrote:
>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/hac
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
inste
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
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
>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
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
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 PROTECTED]
Sent: Monday, September 13, 2004 3:47 PM
To: Soliman, Hesham
Cc: [EMAIL PROTECTED]
Subject: RE: AH and flow
> -Original Message-
> From: Soliman, Hesham [mailto:[EMAIL PROTECTED]
> 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
James Kempf wrote:
If AH is not heavily used today (or used at all), then why is there a
backward compatibility issue with modifying it to protect the flow label?
And, if AH may potentially be deprecated in the near future, then what is
the point of discussing whether to add protection for the flow
>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
In your previous mail you wrote:
I'm looking for some practical justification for this thread.
=> quoting Brian Haberman, the main justification of this thread is itself...
[EMAIL PROTECTED]
IETF IPv6 working group mail
At 2:35 AM +0200 9/11/04, Francis Dupont wrote:
In your previous mail you wrote:
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
At 5:04 PM +0900 9/13/04, Jun-ichiro itojun Hagino wrote:
> 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 t
> => it should be good to get more infos because AH itself is subject
> to calls for deprecation based on the facts ESP can be used in place
> of it in most cases and AH is not very used...
>
If AH is not heavily used today (or used at all), then why is there a
backward compatibility issue with mo
ECTED]
Sent: Sunday, September 12, 2004 12:30 PM
To: Francis Dupont; Soliman, Hesham
Cc: Brian Haberman; [EMAIL PROTECTED]
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 th
Having read the whole thread, I can't see any convincing reason
to include the flow label in AH.
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 c
Steve,
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 l
> 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 w
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
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 ben
On Sun, 12 Sep 2004, Christian Huitema wrote:
> 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 stric
n Haberman; [EMAIL PROTECTED]
> 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 avail
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 li
In your previous mail you wrote:
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??
>> it breaks the
L PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Soliman, Hesham
> Sent: Saturday, September 11, 2004 8:04 PM
> To: [EMAIL PROTECTED]
> Cc: Brian Haberman; [EMAIL PROTECTED]
> Subject: RE: AH and flow label
>
>
>I agree with the drawback you see and it's no
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 d
In your previous mail you wrote:
OK I am worried now. Is there a security hole and potentially serious
problem by not including the Flowlabel in the ICV?
=> according to RFC 3697 there is fortunately none. More, all attacks
on flow labels can't be mitigated by including the flow label in
In your previous mail you wrote:
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...
Given the f
In your previous mail you wrote:
>I have seen several projects started that intend on taking
>advantage of RFC 3697.
>
> => note the RFC 3697 explains why the protection of the flow label is
> not in fact useful. Can you give more details, for instance are flow
> labels
Thanks and good response. The rationale will be important for product
explanation too.
/jim
> -Original Message-
> From: Stephen Kent [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 10, 2004 3:54 PM
> To: Bound, Jim
> Cc: Francis Dupont; [EMAIL PROTECTED]
> Subjec
s Dupont; Brian Haberman; [EMAIL PROTECTED]
> Subject: RE: AH and flow label
>
> 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
> ne
In your previous mail you wrote:
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
In your previous mail you wrote:
For Moonv6 testing we had 6 production implementations of IPsec with
IPv6. Speculation is in early 2005 we will have 11-15. So it has been
implemented for that question and with production code. But how painful
is it to add this to the ICV?
=> it i
ay, September 10, 2004 12:56 PM
> To: Bound, Jim
> Cc: Francis Dupont; [EMAIL PROTECTED]
> 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
> 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.
nodes in the middle are also unlikely to be in a position to verify
the ICV.
if it is, in fact, guaranteed to
tell product implementors to add it.
Thanks
/jim
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Francis Dupont
> Sent: Friday, September 10, 2004 11:06 AM
> To: Brian Haberman
> Cc: [EMAIL PROTECTED]
> Subject: Re: AH and flow
Sent: Friday, September 10, 2004 2:00 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: AH and flow label
>
> > Right. My question was an attempt to see how many implementations
> > support IPSec AH today.
>
> We have one that supports
Yes and good point see my response to Stephen.
Thanks
/jim
> -Original Message-
> From: Pekka Savola [mailto:[EMAIL PROTECTED]
> Sent: Friday, September 10, 2004 1:43 PM
> To: Bound, Jim
> Cc: Francis Dupont; [EMAIL PROTECTED]; Stephen Kent
> Subject: RE: AH and flow
t; 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
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 va
> 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 :)
IETF IPv6 working group mailing list
[EM
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
yo
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
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] O
nt
> 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 inten
am
Cc: Brian Haberman; [EMAIL PROTECTED]
Subject: Re: AH and flow label
In your previous mail you wrote:
I agree with Brian. I'd like to see it protected.
=> can you explain what should be the benefits? because today I can see
only one major drawback: gratuitous incompatibility
On Sep 10, 2004, at 11:06, Francis Dupont wrote:
In your previous mail you wrote:
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.
=> this is the argument which has triggered
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
In your previous mail you wrote:
I agree with Brian. I'd like to see it protected.
=> can you explain what should be the benefits? because today I can see
only one major drawback: gratuitous incompatibility with current
implementations.
[EMAIL PROTECTED]
In your previous mail you wrote:
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.
=> this is the argument which has triggered the question.
I have seen several projects s
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
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
58 matches
Mail list logo
