Re: [tcpm] tcp-auth-opt issue: support for NATs

> -----Original Message-----
> From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> Behalf Of Anantha Ramaiah (ananth)
> Sent: Thursday, August 07, 2008 2:46 PM
> To: Eric Rescorla; Joe Touch
> Cc: Adam Langley; tcpm@ietf.org
> Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs
> 
> 
> While we are at this subject ("supporting NAT's") did we answer the
> basic questions :-
> 
> - Is this a mandatory? Since BGP, LDP and MSDP who are going 
> to be major users of this option, NAT is not going to be in picture.

Those are going to be the major consumers now, but if we aren't
able to keep ahead of various out-of-window TCP attacks, it would
be reasonable for other applications to want to use TCP AO.  I
believe a TLS-over-TCP connection can be destroyed with a bogus
in-window packet; preventing such an attack with TCP AO would be 
valuable if such attacks become easier in the future.

> - Ok, assume you are deciding to support NAT, where do you draw the
> line? Are you also talking about embedded IP addr in the 
> payload (ALG)? Or we don't care?

No ALGs.

-d

> I haven't heard concrete responses (if any) to these above questions.
> Not meant to derail the crypto focus that is currently prevailing in
> this thread.
> 
> -Anantha
> 
> > -----Original Message-----
> > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On 
> > Behalf Of Eric Rescorla
> > Sent: Thursday, August 07, 2008 11:52 AM
> > To: Joe Touch
> > Cc: Adam Langley; tcpm@ietf.org
> > Subject: Re: [tcpm] tcp-auth-opt issue: support for NATs
> > 
> > At Thu, 07 Aug 2008 11:35:38 -0700,
> > Joe Touch wrote:
> > > 
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > > 
> > > 
> > > 
> > > Eric Rescorla wrote:
> > > ...
> > > |> | Because the side doing the passive open doesn't know 
> > which client 
> > > |> | is connecting and it may have multiple instances of 
> > the same key-id?
> > > |> | I don't understand the purpose of the time. Just do trial 
> > > |> | verifications with each key.
> > > |>
> > > |> That's a reason we have a keyID, which, together with 
> the socket 
> > > |> pair, should exactly specify what key to use and avoids 
> > this sort 
> > > |> of trial. If we can live with trials, we can remove the 
> > keyID and 
> > > |> things align much better.
> > > |
> > > | Yes, but this only works if you either (1) know the 
> > address of peers 
> > > | in advance or (2) never assign the same key-id to two different 
> > > | peers.
> > > 
> > > <indiv hat on>
> > > 
> > > If we require the socket pair, then the keyID need be unique only 
> > > within a connection, and we should never need to test 
> > different keys 
> > > -- even with key rollover, the key used should be deterministic.
> > > 
> > > Supporting NATs can be done in two different ways:
> > 
> > I think this is at least potentially an issue even aside from 
> > NAT. When I install keys on my host, you're proposing that I 
> > need to configure both the peer IP address and the key-id. 
> > This isn't necessarily bad, but it does mean that if (for 
> > instance) the other side decides to renumber, nothing will 
> > work absent manual reconfiguration. Is that something people want?
> > 
> > -Ekr
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> > 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm