Subject: Re: [tcpm] security draft input request

From: Andras Salamon <[email-masked]>
Date: Sat, 1 May 2004 16:47:27 +0200

On Fri, Apr 30, 2004 at 09:16:59AM -0400, Mark Allman wrote:
> In particular, we'd like to ask folks to pick one of the options
> that best summarizes your opinion, providing any additional
> justification as you feel is necessary.
> 
> Option #2:

Count me in for this one.

Perhaps some of the folks over on the IDR working group should
also be nudged to recommend randomized source ports for BGP
connections.  As pointed out by Christian Huitema, this would
remove one of the four pillars of an attack.  Unfortunately,
draft-ietf-idr-bgp-implementation-00.txt did not consider source port
randomization in the survey.

draft-ietf-idr-restart-09.txt and draft-ietf-idr-bgp-gr-survey-01.txt do
address the bad BGP application behaviour resulting from TCP connections
terminating unexpectedly, knocking out one of the other pillars.

-- Andras Salamon                   [email-masked]

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Florian Weimer <[email-masked]>
Date: Tue, 04 May 2004 10:32:32 +0200

Mark Allman <[email-masked]> writes:

> Option #3:
>
>     Document the problem, the existing mitigations, as well as exploring
>     additional mitigations.  Note that this "exploration" leaves open
>     the possibility that we will find no mitigations that have
>     consensus.  If that is the case, then this option basically becomes
>     option #2 (possibly with some additional thoughts from this group on
>     why we didn't like anything else in the solution space).

I'm in favor of this option, but I could live with #2 as well.

Apart from that, I feel that the draft, as proposed, is not ready for
publication as an RFC, informational or not.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com,
jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt,
tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 06 May 2004 04:30:13 -0300

At 09:16 30/04/2004 -0400, Mark Allman wrote:

>We'd first like to thank everyone for the rousing discussion on
>Randall's security draft.  As a next step, we'd like to hear opinions on
>the path forward -- from a very high level (i.e., about the topic, in
>general, not the specifics of the i-d).

I have not been able to follow all the messages related to this issue, so I 
beg your pardon if I'm just out of sync.

Readin Randall's draft, I see that in the "Blind data injection attack" 
solution, an additional input check is proposed.
Is there any reason for which the same solution is *not* proposed for the 
"Blind reset attack using the RST bit"?

--
Fernando Gont
e-mail: [email-masked] || [email-masked]

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Thu, 06 May 2004 06:21:05 -0400

Fernando Gont wrote:

> I have not been able to follow all the messages related to this issue, 
> so I beg your pardon if I'm just out of sync.
>
> Readin Randall's draft, I see that in the "Blind data injection 
> attack" solution, an additional input check is proposed.
> Is there any reason for which the same solution is *not* proposed for 
> the "Blind reset attack using the RST bit"? 

We talked about this (the folks in the contributors section) and if I
remember right they all rightly pointed out that the ACK value is
not necessarily something that one can count on in a RST... the
sequence number is I think the only thing that is copied per
793...

R

-- 
Randall R. Stewart
ITD - Transport Technologies
815-477-2127(o) or 815-342-5222(c)

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2004 08:55:06 -0700

Hi, all,

Mark Allman wrote:

> Hi folks!
> Option #1:
>     Do nothing.  There is no problem that needs any sort of IETF
>     attention at all.
> 
> Option #2:
> 
>     Document the problem and the existing techniques that can be used to
>     mitigate the vulnerability.  I.e., spell out the attack and that one
>     could use IPsec or the MD5 option to reduce (or eliminate) the
>     vulnerability.
> 
> Option #3:
> 
> Option #N:
>     We *think* the above options pretty much cover the space at a high
>     level.  However, if you feel there is some slice of the space not
>     covered, please make up a new option.  (But, please do this
>     sparingly.)
> 
> Thanks!
> 
> Mark & Ted

My attempt at option #3 was just posted - draft-touch-anonsec

I do not believe this is fundamentally a TCP issue, as I have stated on 
this list before, and this draft summarizes. That suggests that it is 
not clear whether this should be a WG output; at this time, it is an 
individual submission only.

Joe

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 12 May 2004 20:41:04 +0200

Hi all,

	We're in favour of Option #3. We've just put into a draft some input
(there were also some discussion about that on the list few time ago)
about another problem similar (already well known) to the ones described
in the draft, as well as some proposed changes to TCP in order to
mitigate the threats.

http://www.ietf.org/internet-drafts/draft-azcorra-tcpm-tcp-blind-ack-dos-00.txt

	As always, comments are welcome.

	Kind regards,

	Carlos J.

-- 
Carlos Jesús Bernardos Cano - http://www.it.uc3m.es/cjbc/
GPG FP: 58C3 4227 AF8D 01D4 5A09  A617 E6F2 B23E DAD6 AA40