Subject: [tcpm] new internet draft - drafft-touch-anonsec

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

Hi, all,

The following I-D is soon to appear in the drafts directory; until then, 
here is the title and abstract, and it is available now at:

	http://www.isi.edu/touch/pubs/draft-touch-anonsec-00.txt

At this time, I'm soliciting discussion and feedback on both TCPM and 
IPsec mailing lists, where discussion of the issues of IPsec have been 
ongoing. I track both lists; please do NOT cross-post. I'll 
cross-summarize periodically if it proves necessary.

I'd also like to solicit input on in which WG to proceed.

Joe

----

       ANONsec: Anonymous IPsec to Defend Against Spoofing Attacks
                           draft-touch-anonsec

    Recent attacks on core Internet infrastructure indicate an increased
    vulnerability of TCP connections to spurious resets (RSTs).  TCP has
    always been susceptible to such RST spoof attacks, which were
    indirectly protected by checking that the RST sequence number was
    inside the current receive window, as well as via the obfuscation of
    TCP endpoint and port numbers. For pairs of well-known endpoints
    often over predictable port pairs, such as BGP, increases in the path
    bandwidth-delay product of a connection have sufficiently increased
    the receive window space that off-path third parties can guess a
    viable RST sequence number. This document addresses this
    vulnerability, discussing proposed solutions at the transport level
    and their inherent challenges, as well as existing network level
    solutions and the feasibility of their deployment. Finally, it
    proposes an extension to IPsec configuration called ANONsec that
    intends to efficiently and scalably secure any transport protocol
    from such off-path third-party spoofing attacks.

----

---

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

Joe:

Two quick comments .. and then I will re-read the draft
again and give you a more detailed appriasal... complete
with nits and nats :-D

1) You mention somewhere in the document:
"

*[AUTH - DCCP may be removing cookies from the spec for the
   redundancies discussed above, because the use of cookies at the
   transport layer primarily supports connection mobility (a design goal
   of SCTP, but not DCCP) rather than security.

"

I take issue with the "a design goal of SCTP" if I read this statement
correctly.. SCTP was NEVER designed with mobility in mind. There
are some folks that have written a draft on this I think.. but this
was NEVER the design goal.

2) Throughout the document you focus on BGP. And while I admit
    BGP is a primary concern of mine, I have others too. CallManger and
    other VoIP control systems do at times use TCP instead of SCTP. I
    know H.323 for example did not have SCTP to rely on like sigtran did.
    These types of applications are ALSO at risk and so I think you should
    possibly craft another wording then just "BGP".. I think you really mean
    applications that have long lived TCP connections and exchange
    some critical control information.  Maybe a new term needs to be
    defined.

I will work through your document later... on a second read and give
you detailed comments...

R

Joe Touch wrote:

> Hi, all,
>
> The following I-D is soon to appear in the drafts directory; until 
> then, here is the title and abstract, and it is available now at:
>

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

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2004 11:50:30 -0700

> was NEVER the design goal.

Hi, Randall,

Connection mobility != mobility.

With this clarificiation, is this still something SCTP was not designed 
for? If so, I'm confused about all the multihoming and endpoint 
switching stuff which was around at the start of the SCTP discussions...

>    some critical control information.  Maybe a new term needs to be

The document was certainly motivated by the recent attacks on BGP, and 
(I thought) tried to focus on the more general case of spoofing attacks 
throughout. I'd be glad to cite other examples of related issues, and to 
clarify the document to focus on long-lived TCP in the next revision.

---

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

Joe Touch wrote:

> With this clarificiation, is this still something SCTP was not 
> designed for? If so, I'm confused about all the multihoming and 
> endpoint switching stuff which was around at the start of the SCTP 
> discussions...

Hmm... I am not sure what you mean by connection mobility.. if you
mean multi-homing where an association can use multiple paths.. then
yes.. SCTP has that... but there is no endpoint switching in SCTP that
I know of.. You open a socket on machine A .. and it may have
IP-A/IP-B and IP-C ... your association may be across those
3 IP addresses .. i.e. you can send and receive on any of those
address to your bound port .. but the endpoint/socket does not
move off the machine or to some other socket....

> (I thought) tried to focus on the more general case of spoofing 
> attacks throughout. I'd be glad to cite other examples of related 
> issues, and to clarify the document to focus on long-lived TCP in the 
> next revision. 

That would be great... I will be doing a detailed read and
see if I can't figure out a way to suggest something...

R

>>> At this time, I'm soliciting discussion and feedback on both TCPM 
>>> and IPsec mailing lists, where discussion of the issues of IPsec 
>>> have been ongoing. I track both lists; please do NOT cross-post. 
>>> I'll cross-summarize periodically if it proves necessary.
>>>

---

From: Joe Touch <[email-masked]>
Date: Thu, 06 May 2004 15:39:29 -0700

Randall Stewart (cisco) wrote:
> yes.. SCTP has that...

That's what I meant.

> but there is no endpoint switching in SCTP that

Well, that's not something that SCTP specs, but once you allow multiple 
IP addresses, that's not out of the question, IMO. I don't recall 
whether SCTP allowed 'renegotation' of the set of IP addresses, but if 
so, that becomes even more possible.

I.e., I appreciate that this may be a raw nerve of sorts, but there's 
been a convergence of mobility, multihoming, transport mobility (moving 
machines), and connection 'agility' (perhaps a better term for SCTP's 
original design?).

The point I was trying to make (let me know if there's a better way to 
rephrase in the revision) is that SCTP's cookies are to demux (in a 
way), not specifically to prohibit spoofers, IMO.