Subject: RE: [tcpm] WG consensus sought (deadline 5 May): abort timeout negotiation

From: [email-masked]
Date: Thu, 29 Apr 2004 12:45:49 -0500

> 
> Exactly.
> 
> We actually also play with a slightly different scenario, 
> where the TCP 
> session runs over HIP. This lets you plug in anywhere - your 
> connections 
> are bound to the host identities and thus survive the address 
> changes at 
> the new location. The issue then is that by the time you plug 
> back in, 
> the retransmission abort timer has on the peers may have 
> fired and the 
> connections have been reset.
> 

On the record ...

ATO negotiation might be useful, especially for sessions that use secure
channels (TLS or SSH as Mark pointed out) and require a password for
authentication. It's a hassle to type in the password over and over
again every few minutes. 

So, I'd like to support this as a working group item. 

Off the record ...

I am not sure how ATO will facilitate host portability. There are quite
a few roadblocks apart from ATO that affect portability more than ATO.
Here are a few:

1. Unless the laptop has a fixed IP address or the DHCP somehow assigns
the same address to a particular interface, the session cannot continue.

2. I am skeptical about how soon HIP could be deployed. HIP relies
heavily on DNSSec, and one thing I have learned from studying several
PKI cases is that it take for ever to materialize. Although  DNSSec is
not PKI per se, it too will take a long time (10+ years) before being
useful. (I might be a little pessimistic here, but ...) 

3. The application layer itself might have timed session keys so even
though the lower layer might be active, the application layer might
abort the session for security reasons.

But, in spite of all these issues, TCP should do its job ....  So I
would like to see this as a WG item.

Yogesh

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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 30 Apr 2004 08:53:25 +0200

Yogesh,

thanks for the comments!

> the same address to a particular interface, the session cannot continue.

True. Connections need to bind to something fairly static, like HIP 
identities. (The MobileP equivalent - home addresses? - may also work, 
but I don't know MobileIP very well.)

> useful. (I might be a little pessimistic here, but ...) 

It only depends on DNSSec for peer authentication. For opportunistic 
encryption, it doesn't. (We use HIP mainly for its mobility features and 
not because it adds much in terms of security.)

> abort the session for security reasons.

Also true. But as you know, that's a separate issue of course. If it 
turns out that once TCP survives intermittent connectivity, application 
timers start to become an issue, then those protocols and applications 
will require changes as well.

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories