Re: Merge NAT-PT approaches?

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 29/12/2007, a las 21:04, Brian E Carpenter escribió:

> 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 was considering the case for instance where the host dynamically  
discovers the NAT64 (i.e. no manual configuration of which NAT64 is  
used by the user) and state is created in the host (either v6 or V4)
in this case, it is possible that we need to protect the creation of  
this state, since it may results in new attacks (e.g. redirection  
attacks)

Besides, someone mention the other day, we need to make this nat64  
approach compatible for instance with dnssec

I guess that depending the actual approach we may also need to  
consider the impact on bgp security (for instance if the ISP having  
these boxes will announce routes to the v4 internet or to the v6  
internet through interdomian)

Of course some or all of these may be non issues depending on the  
considered appraoch, but my suggestion was that we should first have  
a clear picture of the requirements for the solution and application  
scenario and then perfrom a threat analysis. I guess it is just too  
soon to state that TLS and passowrd would be enough


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

i agree with this and i guess this is security requirement that we  
should impose to the solution. I would probably add explicitly that  
the solution should not break dnssec and bgp security (even this  
would be included in the previous general requirement)

Regards, marcelo


>    Brian