Re: [conex] ConEx Dest Opt

Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de> Mon, 21 October 2013 17:29 UTC

Return-Path: <mirja.kuehlewind@ikr.uni-stuttgart.de>
X-Original-To: conex@ietfa.amsl.com
Delivered-To: conex@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C39311E86C1 for <conex@ietfa.amsl.com>; Mon, 21 Oct 2013 10:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.065
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLQuUiAOyPTH for <conex@ietfa.amsl.com>; Mon, 21 Oct 2013 10:29:07 -0700 (PDT)
Received: from mailsrv.ikr.uni-stuttgart.de (mailsrv.ikr.uni-stuttgart.de [129.69.170.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0E02611E86BD for <conex@ietf.org>; Mon, 21 Oct 2013 10:29:07 -0700 (PDT)
Received: from netsrv1.ikr.uni-stuttgart.de (netsrv1-c [10.11.12.12]) by mailsrv.ikr.uni-stuttgart.de (Postfix) with ESMTP id CC698602EE; Mon, 21 Oct 2013 19:29:05 +0200 (CEST)
Received: from vpn-2-cl195 (vpn-2-cl195 [10.41.21.195]) by netsrv1.ikr.uni-stuttgart.de (Postfix) with ESMTP id C5D5760038; Mon, 21 Oct 2013 19:29:05 +0200 (CEST)
From: Mirja Kuehlewind <mirja.kuehlewind@ikr.uni-stuttgart.de>
Organization: University of Stuttgart (Germany), IKR
To: Bob Briscoe <bob.briscoe@bt.com>
Date: Mon, 21 Oct 2013 19:29:05 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20101217.1207316)
References: <201310191353.14159.mirja.kuehlewind@ikr.uni-stuttgart.de> <201310191602.r9JG2NjW010985@bagheera.jungle.bt.co.uk>
In-Reply-To: <201310191602.r9JG2NjW010985@bagheera.jungle.bt.co.uk>
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: <201310211929.05331.mirja.kuehlewind@ikr.uni-stuttgart.de>
Cc: conex@ietf.org
Subject: Re: [conex] ConEx Dest Opt
X-BeenThere: conex@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Congestion Exposure working group discussion list <conex.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/conex>, <mailto:conex-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/conex>
List-Post: <mailto:conex@ietf.org>
List-Help: <mailto:conex-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/conex>, <mailto:conex-request@ietf.org?subject=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
> <http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-tcp-02#section-5.3>
> 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 
document?

>
> >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:
> <http://tools.ietf.org/html/draft-briscoe-conex-re-ecn-tcp-02#section-8.1>
>
> 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 
else)...?

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

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?

Mirja

>
>
> 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
email: mirja.kuehlewind@ikr.uni-stuttgart.de
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------