Re: Merge NAT-PT approaches?

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

On 2007-12-29 07:05, Iljitsch van Beijnum wrote:
> On 28 dec 2007, at 15:43, marcelo bagnulo braun wrote:
>
> > > I don't think reusing parts from shim6 makes a lot of sense for 
> > > authentication. There are already several datagram based 
> > > authentication mechanisms, and they can get quite complex. If a host 
> > > needs to authenticate towards a NAT-PT translator, it would be much 
> > > simpler to set up a TLS-protected TCP session and then do simple 
> > > user/password authentication.
>
> > i think this depends on the application scenario that the mechanism is 
> > designed to work on. Having TLS + user/password may be ok for some 
> > scenarios, but you need to provision the tls certs and the user and 
> > password, which may be ok for some application cases and not so ok for 
> > others. So i would suggest we first figure out which is the 
> > application scenario where the mechanisms is supposed to work on, then 
> > we figure out the threats and then try to work on security tools for that
>
> I'm assuming a relatively simple model where users have their packets 
> translate by a NAT-PT translator that is outside their own network or 
> their ISP's network. 

s/is/may be/ ?

> Since it would obviously be problematic to accept 
> and translate packets from the entire internet, we need some simple 
> authentication.
>
> This would be very similar to IMAP or POP authentication in the presence 
> of TLS: the TLS itself isn't part of the authentication but is only used 
> to make sure that the password travels over the network encrypted. In 
> theory certificates could be a complication, but in practice, all hosts 
> that come with a web browser already have a bunch of root certificates 
> so this isn't much of an issue.
>
> I don't think we need strong security as in IPsec for the data packets, 
> but if someone else knows a reason why we do, I'm listening.

I agree with Iljitsch on this. We need to defend "new NAT-PT"
against threats that it creates, which are essentially exploits of
any signaling between the host and the translator. There's no
point in defending it against generic threats such as injection
of bogus packets.

   Brian