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.

- 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?

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