[e2e] Introduction to ATP

[Jason Gao]

> -----邮件原件-----
> 发件人: Stephen Sprunk [mailto:stephen at sprunk.org] 
> 发送时间: 2005年3月15日 8:30
> 收件人: Jason Gao; end2end-interest at postel.org
> 主题: Re: Introduction to ATP
> 
> Thus spake "Jason Gao" <jag8719 at vip.sina.com>
> > Patching TCP software to support mobility and multi-home is 
> not difficult.
> > But widely deploying the new TCP implementation may be an 
> enduring work.
> ...
> > SCTP supports multi-home, and it is quite easy to extend it 
> to support 
> > mobility. But as SCTP is already quite heavy weighted, and its 
> > congestion control mechanism arguably suffers same trouble 
> as TCP, it 
> > is difficulty
> to
> > persuade mass users to accept SCTP.
> ...
> > The name of Asymmetric Transport Protocol is somewhat historical.
> > ATP takes advantages of asymmetric cryptography (and asymmetry of 
> > communication). It is designed to be an alternate of 
> transport layer 
> > protocols, alongside of TCP and UDP [RFC768].
> 
> I fail to see how ATP, as a new transport protocol, is any 
> more likely to be implemented in a critical mass of 
> end-systems than, say, SCTP or an improved TCP.  It's the 
> same problem.
>

> > There are three connection modes in ATP: fast-mode, normal mode and 
> > encrypted transport mode. In the host environment, each ATP 
> connection 
> > is uniquely associated with a 64-bit connection key.
> 
> Why 64 bits?  If you used 128-256 bits, that gives you enough 
> entropy to derive an encryption key directly.  If you're not 
> using it for that, then surely a 32-bit connection ID would suffice.
> 
Well, it is a trade-off.  64 bits can be be split into two 32 bits. The two 32 bit words can be embedded in the  interface ID fields of the source and destiantion IPv6 address, respectively.

> > In the context of each normal mode ATP connection, there is 
> a shared 
> > secret.  The shared secret is established in Elliptic Curve 
> > Diffie-Hellman [ECC] key agreement process when the 
> connection is set up.
> 
> I'm not familiar with ECDH; does it protect against 
> Man-In-The-Middle attacks?  I don't see how you'll get around 
> that without a PKI or pre-existing shared secrets -- one 
> doesn't exist yet and the other doesn't scale to real usage.
> 
We assume that
...
²	Upper Layer Application is willing and able to defense against man-in-the-middle attack.
...
Say, taking use of SRP.

> > ATP endpoint seals every ATP packet with Integrity/Identity 
> Check Code 
> > (ICC).  In normal mode ICC is calculated by applying HMAC-SHA1 
> > [RFC2104] [RFC3174] on the ATP packet header with the 
> shared secret as 
> > the key.
> 
> Why not on the payload as well?  Once you've incurred the 
> cost (and legal
> problems) of requiring crypto, doing the payload too is minor.
> 
Oh thanks! That's a mistake when I wrote the introduction. In section 3.4, ICC and packet legitimacy, I mention that the 80-bit ICC in normal mode is actually split into a 16-bit CRC part and a 64-bit SHA1 part. The CRC part cover the full payload while the SHA1 part cover the header. It's intended to give some possiblity of parallel processing.

> > As far as only the connected peers know both the connection key and 
> > the shared secret, integrity of the ATP packet header and 
> identity of 
> > the ATP packet source are secured by ICC.
> 
> Is this meant to imply that if the connection key were 
> discovered but not the shared secret, the ICC would be 
> broken?  That would mean you really have two secrets to 
> protect -- why not just one?
>
I mean if the connection key were discovered - that's easy -  but not the shared secret, possibility of undetected modification of the payload or the ATP header is so low that integrity and identity can be considered being secured.

> > In fast mode, ATP endpoints do not establish a shared secret, and 
> > agree on the connection key only. The 64-bit connection key solely 
> > acts the identity check role. ICC is a CCITT-CRC-16 code [CRC] that 
> > weakly protects packet integrity.
> 
> So "fast mode" is really "weak mode"?
> 
> How does the connection key factor into the CRC16 algorithm?  
> How can you prevent the key from being recovered since CRC16 
> is easily reversible when the plaintext is available?  I'd 
> hope that "weak mode" is optional for implementations.
> 
That's another trade-off. In very high speed computation situations where multi-home (or multi-path) is welcomed, and the networks are  physical secured, say, full-optical networks, unnecessary transport layer security may be unwelcomed.

> > In encrypted transport mode ATP endpoints use 
> AES-IV-SHA1-80 algorithm 
> > to protect privacy of the payload, integrity of the full 
> packet, and 
> > identity of the packet source. AES-IV-SHA1-80 algorithm is 
> integration 
> > of AES [FIPS-197] and SHA1-80 [RFC3174].
> 
> SHA1-80 would seem to be woefully underpowered.  Even 
> SHA1-160 only requires
> 2^51 (IIRC) work to find collisions after recent revelations; 
> SHA1-80 is theoretically breakable with anything more 
> powerful than a four-function calculator.
> 
> Why not use the NIST-approved Counter Mode, which was 
> specifically designed for packet switching applications?  
> Reinventing the wheel is very dangerous in the crypto world.  
> Trying to combine integrity and encryption into a single 
> operation is also difficult and fraught with mistakes; take a 
> look at the proposed OCB mode for one way to do it right.
> 
> > AES encryption key is installed by the upper layer 
> application (ULA), 
> > or derived from the shared secret on request of ULA; 64-bit initial 
> > vector is the low-order 64-bit part of the result of 
> applying SHA1-80 
> > on the ATP packet header. High-order 16 bits are exploited for 
> > preliminary integrity check. Encrypted transport mode is not only a 
> > feature of mobility and multi-home but a simple and useful 
> feature of 
> > security as well.
> 
> You're using a 64-bit IV for a 128/192/256-bit block cipher?
> 
An ATP endpoint does not really need to know the real identity of the remote endpoint. It just want to be sure that the successive packets come from the same source.

In encrypted transport mode AES key is not derived from SHA1-80 of something. It is installed by the upper layer application or derived from the shared secret which is (at least 283 bits [SECT283K1].

As to the initial vector, 64-bit is only the half of the AES block size, but I don't think it break AES  if we do padding right. Anyway, it is just a (pseudo-)random salt.

Best regards,
Jason.