Re: [conex] ConEx Dest Opt

[Mirja Kuehlewind <[e-mail]>]

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