Re: [tcpm] [Fwd: New Version Notification for draft-touch-tcp-ao-nat-00]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tcpm] [Fwd: New Version Notification for draft-touch-tcp-ao-nat-00]



And to followup -- TCP-AO-NAT is a good idea.  As I have
explained in previous emails to TCPM, I would prefer it
work with a TCP server behind a NAT, as well as the TCP
client behind a NAT, but it's a reasonable trade-off in
complexity as most of the use cases where AO is important
have publicly-accessible TCP servers.

I'm sure some other folks have something to say about
TCP-AO working for a TCP-AO client behind a NAT44 or
behind a NAT64?

-d
 

> -----Original Message-----
> From: Dan Wing [mailto:dwing at cisco.com] 
> Sent: Tuesday, November 17, 2009 3:37 PM
> To: 'Joe Touch'; 'tcpm Extensions WG'
> Subject: RE: [tcpm] [Fwd: New Version Notification for 
> draft-touch-tcp-ao-nat-00]
> 
>  
> 
> > -----Original Message-----
> > From: tcpm-bounces at ietf.org [mailto:tcpm-bounces at ietf.org] On 
> > Behalf Of Joe Touch
> > Sent: Monday, October 19, 2009 7:50 AM
> > To: tcpm Extensions WG
> > Subject: [tcpm] [Fwd: New Version Notification for 
> > draft-touch-tcp-ao-nat-00]
> > 
> > Hi, all,
> > 
> > The following provides info on the draft that describes the NAT
> > extensions to TCP-AO. They have been submitted as 
> individual for now,
> > with the intent of incorporating the result into the TCP-AO 
> > doc *if* we
> > have time before publication and *if* there is consensus to do so.
> > 
> > Otherwise, it can published separately as either PS or 
> > experimental, if preferred.
> 
> Thanks for publishing this document, Joe.  I would prefer to see it
> incorporated into the base TCP-AO document, as there are legitimate
> uses for TCP-AO for TCP clients behind a NAT44 or NAT64, such as to 
> protect long-lived TLS-over-TCP sessions (SIP, XMPP, HTTP, and 
> perhaps will be necessary for the forthcoming SmartGrids work).
> 
> -d
> 
> 


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.