[Fwd: [Ipsec] new internet draftt - draft-touch-anonsec]

This is relevant to the ongoing RR optional/MUST discussion in the 
list.  I guess this increases the list of cases where RR, even if the 
MOBIKE protocol spec declares it optional, should be checked by the GW.  
Notice that I am still saying that leaving the decision to the 
discretion of the responder (w.r.t. the address change exchange) works 
just fine.  I must admit, however, that the list of cases where RR is a 
MUST is growing :-).

Also, what is the relationship between this and the opportunistic 
encryption work?  Is -anonsec- more general (I only scanned both 
proposals very briefly, so others might want to make a definitive 
assessment here)?  Thanks.

regards,
Lakshminath

-------- Original Message --------
Subject: 	[Ipsec] new internet draftt - draft-touch-anonsec
Date: 	Thu, 06 May 2004 08:51:52 -0700
From: 	Joe Touch <[email protected]>
To: 	ipsec mailingList <[email protected]>



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.

----

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAml8YE5f5cImnZrsRAsYZAJ9Oz0EBcM4fN+d3Y02vVJpVly2zRQCg4DDg
IO13SoCIFWm3b45iGDxP1fY=
=lYIx
-----END PGP SIGNATURE-----