Re: [conex] ConEx Dest Opt

[Bob Briscoe <[e-mail]>]

Mirja,

At 18:29 21/10/2013, Mirja Kuehlewind wrote:
>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?

It's the only place it can be discussed. So yes.
It's experimental, so the IESG should be able to allow it through.


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

The requirement is already stated in 
abstract-mech, so no need to say it elsewhere yet.
If it were put anywhere, it would be in a ConEx transport spec.
But there's no need to mention this even in conex-tcp-mods at this stage.

It's definitely not relevant to conex-dest-opt. 
All you have to say there is that the field is immutable.


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

Don't worry - it's not important. It's a subtle 
point that there are two ways to protect yourself:
- an obvious and visible way (AH)
- a randomised stealth way that also has the nice 
effect that the network cannot see who is 
protected, so it doesn't risk its reputation and 
avoids attacks anyone, in case it attacks someone who can detect the attack.


Bob



> >
> > >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: [phone]
>email: [e-mail]
>web: www.ikr.uni-stuttgart.de
>-------------------------------------------------------------------

________________________________________________________________
Bob Briscoe,                                                  BT