On 2011-05-11 00:38, Ran Atkinson wrote:
> Earlier, Brian Carpenter wrote:
>> I suggest squaring this circle by retaining the MUST NOT (which IMHO
>> is the present consensus) but making it clear in the security
>> considerations that there will be exceptions. The problem here is that
>> the RFC 21
Earlier, Brian Carpenter wrote:
> I suggest squaring this circle by retaining the MUST NOT (which IMHO
> is the present consensus) but making it clear in the security
> considerations that there will be exceptions. The problem here is that
> the RFC 2119 language doesn't provide MUST NOT UNLESS...,
bject: Re: Flow label drafts updated
Brian E Carpenter wrote:
> On 2011-05-10 01:02, RJ Atkinson wrote:
>
>> A much more reasonable approach would be to say (edit to taste):
>>
>> "The Flow Label SHOULD NOT be changed in transit."
>
> The author
Brian E Carpenter wrote:
> On 2011-05-10 01:02, RJ Atkinson wrote:
>
>> A much more reasonable approach would be to say (edit to taste):
>>
>> "The Flow Label SHOULD NOT be changed in transit."
>
> The authors really need to hear that from more than one person, or to
> hear from the WG C
Hi again Ran,
On 2011-05-10 01:10, RJ Atkinson wrote:
> On 08 May 2011, at 19:47 , Brian E Carpenter wrote:
>> But it's really playing with words to assert that a firewall which
>> chooses to overwrite the field is "supporting" it in the sense
>> intended by the phrase "Hosts or routers that do n
Hi Ran,
On 2011-05-10 01:02, RJ Atkinson wrote:
> On 08 May 2011, at 19:06 , Brian E Carpenter wrote:
>> Maybe it's just the use of the word "immutable" that is causing the
>> problem here, because it implies something that physically isn't true.
>
> I think that is a very very important part, p
On 08 May 2011, at 19:47 , Brian E Carpenter wrote:
> But it's really playing with words to assert that a firewall which
> chooses to overwrite the field is "supporting" it in the sense
> intended by the phrase "Hosts or routers that do not support the
> functions of the Flow Label field...".
It
On 08 May 2011, at 19:06 , Brian E Carpenter wrote:
> Maybe it's just the use of the word "immutable" that is causing the
> problem here, because it implies something that physically isn't true.
I think that is a very very important part, possibly the
central element, of this discussion. This
As I said, I don't like what I (re-)suggested.
But if we want routers to actually use this, then we need it to be
sufficiently reliable. If too much stuff won't get balanced, operators
will not accept the solution.
Yours,
Joel
On 5/8/2011 9:55 PM, Brian E Carpenter wrote:
Joel,
My loop det
Joel,
My loop detector just buzzed. This is more or less where we were
a couple of drafts ago, but people said "don't say that". Now,
I never delete old xml2rfc files, so I can bring back that text.
However, I'd like the WG chairs to decide...
Bert is correct below - if a load balancer doesn't ba
I rather hate the following idea, and I am not sure that security
gateways would be willing to follow it.
In order for flow label usage to actually help the ECMP hardware, we
have to expect it to work.
What if security gateways were expected to put reasonable, flow
distributing, flow -labels o
On 2011-05-07 23:33, RJ Atkinson wrote:
> On 06 May 2011, at 21:23 , Brian E Carpenter wrote:
>> I'm hard over on a MUST NOT. What we've been arguing with Thomas is really
>> about
>> how to express the warning that the flow label might get undetectably
>> changed by
>> an on-path device, even t
Brian E Carpenter wrote:
> Nodes MUST NOT change the flow label. But since you can't detect
> whether
> it's been changed, mechanisms using the flow label for some purpose
> must
> be robust against unanticipated changes.
If I may try to express what I perceive the problem to be, we have been tol
On Behalf Of Brian
> E Carpenter
> Sent: Tuesday, May 03, 2011 5:58 PM
> Subject: Re: Flow label drafts updated
>
>> and also the apparent decision to write these documents in a manner
>> intended to legislate reasonable security measures (if applicable only
>> in
On 06 May 2011, at 21:23 , Brian E Carpenter wrote:
> I'm hard over on a MUST NOT. What we've been arguing with Thomas is really
> about
> how to express the warning that the flow label might get undetectably changed
> by
> an on-path device, even though that is against the standard. A node dow
below...
On 2011-05-07 07:50, George, Wes E [NTK] wrote:
> -Original Message-
> From: Thomas Narten [mailto:nar...@us.ibm.com]
> Sent: Friday, May 06, 2011 9:27 AM
> Subject: Re: Flow label drafts updated
>
> Is the UDP port number mutable? Is the TCP sequence number
Ran,
I'm obliged to repeat myself: there has been endless feedback in the
WG that the flow label remains defined as immutable, so any middlebox
that changes it is violating the standard.
Of course the chairs can tell me this is now an open issue, but we
have been over it many times.
Regards
B
-Original Message-
From: Thomas Narten [mailto:nar...@us.ibm.com]
Sent: Friday, May 06, 2011 9:27 AM
Subject: Re: Flow label drafts updated
Is the UDP port number mutable? Is the TCP sequence number immutable?
[WEG] I think both are immutable because there's a checksum to detect ch
"George, Wes E [NTK]" writes:
> [WEG] now it's my turn to be confused by your comment, Brian. I missed this
> detail of interpretation when reviewing the draft for
> LC, and I apologize, but I think it's pretty important...
> >From the 3697bis draft:
> "There is no way to verify whether a flow l
+1
On Thu, May 5, 2011 at 10:48 AM, George, Wes E [NTK]
wrote:
>
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian
> E Carpenter
> Sent: Tuesday, May 03, 2011 5:58 PM
> Subject: Re: Flow label drafts updated
>
>> and also the apparent
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Brian E
Carpenter
Sent: Tuesday, May 03, 2011 5:58 PM
Subject: Re: Flow label drafts updated
> and also the apparent decision to write these documents in a manner
> intended to legislate reasonable security measur
On 03 May 2011, at 17:58 , Brian E Carpenter wrote:
>> and also the apparent decision to write these documents
>> in a manner intended to legislate reasonable security measures
>> (if applicable only in selected deployments) out of existence.
>
> I don't understand this comment. The flow label
Ran,
> I am troubled by the apparent decision to ignore legitimate
> operational security considerations (e.g. about covert channels)
We should certainly mention the covert channels issue in the
security considerations of 3697bis.
> and also the apparent decision to write these documents
> in
Hi,
My thanks to all of the editors for their joint work to sort out
these drafts and to progress them together. It is substantial
work to undertake. The drafts generally seem fine and are
eminently readable.
However, the "Security Considerations" for both
draft-ietf-6man-flow-ecmp-02 and draf
24 matches
Mail list logo
