Re: [conex] ConEx Dest Opt

Mirja Kuehlewind <> Mon, 21 October 2013 17:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C39311E86C1 for <>; Mon, 21 Oct 2013 10:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.065
X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wLQuUiAOyPTH for <>; Mon, 21 Oct 2013 10:29:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0E02611E86BD for <>; Mon, 21 Oct 2013 10:29:07 -0700 (PDT)
Received: from (netsrv1-c []) by (Postfix) with ESMTP id CC698602EE; Mon, 21 Oct 2013 19:29:05 +0200 (CEST)
Received: from vpn-2-cl195 (vpn-2-cl195 []) by (Postfix) with ESMTP id C5D5760038; Mon, 21 Oct 2013 19:29:05 +0200 (CEST)
From: Mirja Kuehlewind <>
Organization: University of Stuttgart (Germany), IKR
To: Bob Briscoe <>
Date: Mon, 21 Oct 2013 19:29:05 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <> <>
In-Reply-To: <>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <>
Subject: Re: [conex] ConEx Dest Opt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Oct 2013 17:29:11 -0000

Hi Bob,

I cc'ed the list.

Thanks for you reply, see comments below.

On Saturday 19 October 2013 18:02:22 Bob Briscoe wrote:
> Mirja,
> Cc any reply to the list if you want.
> At 12:53 19/10/2013, Mirja K├╝hlewind wrote:
> >Hi,
> >
> >I'm currently working on the CDO draft. If have two questions where I'm
> > not sure about the right answer at the moment (independent of crediting
> > actually). Maybe someone of you already has an answer:
> >
> >1) Should ConEx marked packets preferentially not be dropped? This could
> > help the audit but it would overestimate the congestion level.
> >  -> I would say no, because chances that marked packets get drop are
> > anyway lower (?) because marks are usually sent after a window reduction.
> > And this could potentially be exploited negatively...?
> You're thinking only in terms of what a compliant
> TCP will do, not what an attacker might do...
> Optionally, preferential drop should discard with
> the following drop pref (1 means drop first):
> Not-ConEx or no destopt: 1
> X (but not L,E or C):   2
> X and L,E or C:         3
> Otherwise a DDoS source can just not re-echo
> ConEx and flood the queues before the first audit
> function without being limited by an ingress policer.
> There is no known way to game this - Mark
> Handley, me and others thought through this when
> we were first considering re-ECN as a mitigation of DDoS.
> See
> <>
> for useful wording on preferential discard (but with re-ECN codepoints).
> However, this has to be OPTIONAL because it's not
> so neat to expect a queue to drop based on a
> destopt, which is meant to be e2e. We should ask
> on the list whether this is likely to be
> controversial with the IESG. I think OPTIONAL should be OK.
Okay, agree, but should this be described/discussed in the ConEx Dest Opt 

> >2) ConEx marks should be immutable. What to do or how to detect if someone
> >changed the marking on the path.
> You can borrow the words from the last para of
> the re-ECN Security Considerations if you want:
> <>
> This would require some future modification to
> the L4 transport, so the receiver can feed back
> ConEx markings to the sender (re-re-feedback) -
> only random ones - don't need it all the time. We
> don't have to do this now, just allow for it in future.
Not sure, if I even want to mention this option in the CDO draft (or anywhere 

> Alternatively, an IPsec authentication header
> could be used, because the destopt would
> automatically be covered by e2e IPSec AH.
> However, the text says it's better not to reveal
> to the network whether the endpoints are
> protecting against changes to ConEx fields.
> Otherwise a network will just attack packets that
> aren't protected. it is preferable for random
> checks to tend to protect everyone, rather than
> just protecting those doing the checks.
Not sure I get your point here. If you want to be protected, use IPSec AH, no? 
I don't see a problem here.

> >Furthermore, should invalid bit combinations
> >be ignored or should the packet get dropped or something else...?
> >  -> Don't know...
> I think the only invalid bit combination is not-X with L,E or C.
> This could be solved by just not having the X
> flag. The existence of the destopt could imply
> ConEx-capable. However, that would make header overhead variable within a
> flow.
> Easiest to say L,E or C implies ConEx-capable, even if X is off.
> Then you have to say the packet should be
> forwarded unchanged and the inconsistency
> ignored. This would allow some future meaning to
> be assigned to L,E or C with X off.
Currently the drafts says if X is off, L, E and C are undefined. Yes, that 
allows for future usage but would imply to ignore L, E or C if X is off. This 
contradicts your first sentence which is saying that L, E or C implies 

I believe I tent to leave it as it is, saying that E, L, and C should be 
ignored if X is off and additionally saying explicit that no action (drop) 
should be take if this case occurs. Okay?


> Bob
> >Any ideas?
> >
> >Mirja
> ________________________________________________________________
> Bob Briscoe,                                                  BT

Dipl.-Ing. Mirja K├╝hlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: +49(0)711/685-67973