[e2e] where to put endpoint authentication?

[Joe Touch]

marcelo bagnulo wrote:

> Hi Joe,
> 
> Have you considered the work being done in HIP about providing cryptographic
> based endpoint identifiers? Perhaps this could provide some useful tools for
> this...
> 
> Regards, marcelo

Hi, Marcelo (et al.),

HIP (IMO) appears similar to IPsec in the protection it provides (i.e., 
network layer), and is very similar to IPsec tunnel mode in how endpoint 
ID is somewhat decoupled from forwarding ID (like E2E tunnels, the 
endpoint needs to 'route' based on these endpoint IDs, though).

Joe

>>-----Mensaje original-----
>>De: end2end-interest-bounces at postel.org
>>[mailto:end2end-interest-bounces at postel.org]En nombre de Joe Touch
>>Enviado el: viernes, 07 de mayo de 2004 20:24
>>Para: end2end-interest at postel.org
>>Asunto: [e2e] where to put endpoint authentication?
>>
>>
>>Hi, all,
>>
>>The IETF TCPM mailing list has been discussing recent TCP RST spoofing
>>attacks on BGP and how best to prevent those attacks.
>>
>>I recently posted an Internet Draft that summarizes the issues, for
>>context: draft-touch-anonsec-00.txt
>>
>>During the writing of this draft, a question arose regarding the role of
>>TCP's sequence number in authentication, and where best to place
>>endpoint authentication. (see sections 3.1 and 4.1 in particular).
>>
>>The question might be useful to raise here:
>>
>>	1) should sequence numbers be used for authentication?
>>
>>		IMO, the sequence space is primarily for:
>>			1. receiver reordering
>>			2. congestion control
>>			3. duplicate detection
>>
>>		TCP drops segments outside the receive window
>>		primarily, IMO, to discard stale segments
>>
>>		draft-tcpm-tcpsecure narrows the valid receive
>>		window for RST segments (allowing them only
>>		at the end of the current receive window),
>>		primarily to protect against off-path RST
>>		spoofing attacks
>>
>>		there have been previous suggestions to increase
>>		the TCP sequence space to 64 bits, being revisited
>>		to see if the additional 32 bits can provide the
>>		equivalent of a segment 'cookie'
>>
>>	2) do transport protocols need authentication?
>>
>>		current transport authentication - cookies, MD5
>>		signatures, etc., protect against off-path spoofing
>>
>>		such spoofing relies on forgery of several values:
>>			- IP source/dest addresses
>>			- TCP ports/sequence numbers
>>
>>		such attacks can be considered either:
>>			- primarily network forgery
>>			- forgery at both network and transport layers
>>
>>		where is protection more appropriate/useful?
>>			- network (IMO)
>>			- transport
>>			- both are needed
>>
>>	3) are cookies reasonable authentication for transport layers?
>>
>>Thoughts, either privately or to this list, appreciated. Additional
>>comments have been circulating on the IETF TCPM, IPsec, and MOBIKE
>>mailing lists, FYI.
>>
>>Joe
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/end2end-interest/attachments/20040510/4ac07692/signature-0001.bin