Subject: Merge NAT-PT approaches?

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 20 Dec 2007 12:28:49 +0100

Hi Brian (and others),

The NAT-PT discussion pretty much stopped after the v6ops session two  
weeks ago. So let me kick it in gear again:

I think it would be useful to merge our approaches. Mine has the  
benefit that the changes are minimal on the host side and changes on  
the NAT-PT box side are probably unnecessary for a large subset of all  
possible communications. Your approach has the advantage that it can  
provide a complete solution for pretty much every type of  
communication, including a decent chunk that probably can't even be  
supported by IPv4 NAT.

So what I'm thinking is that we come up with something where hosts do  
A record lookups but otherwise use NAT-PT pretty much the way it is  
today. I've had some private feedback on anycast, so I'm thinking the  
top 96 bits would come from either direct manual configuration or they  
are obtained from a magic DNS name in the domain that the host has  
learned through manual configuration or DHCP.

The shim approach would then kick in when the host needs to do more  
advanced communication, for instance, when it needs to know or set the  
source address / source port, it needs incoming connections or when  
there needs to be authentication from the host towards the NAT-PT  
gateway.

We probably want to define some API that applications can use to  
invoke the above but also IPv6 firewall traversal for regular IPv6  
connectivity. (Unless there already is an API we can reuse?)

Iljitsch

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Dec 2007 16:47:11 +1300

I'm sympathetic to the idea. Bringing in the shim action
only when it's actually needed sounds good in principle.
The devil is in the details, of course, but we can
investigate that off-list if people would like us
to follow this up.

(Due to the midsummer break where I now live,  I won't
be on line so much for the next ten days.)

    Brian

On 2007-12-21 00:28, Iljitsch van Beijnum wrote:
> I think it would be useful to merge our approaches. Mine has the benefit 
> that the changes are minimal on the host side and changes on the NAT-PT 
> box side are probably unnecessary for a large subset of all possible 
> communications. Your approach has the advantage that it can provide a 
> complete solution for pretty much every type of communication, including 
> a decent chunk that probably can't even be supported by IPv4 NAT.
> 
> So what I'm thinking is that we come up with something where hosts do A 
> record lookups but otherwise use NAT-PT pretty much the way it is today. 
> I've had some private feedback on anycast, so I'm thinking the top 96 
> bits would come from either direct manual configuration or they are 
> obtained from a magic DNS name in the domain that the host has learned 
> through manual configuration or DHCP.
> 
> there needs to be authentication from the host towards the NAT-PT gateway.
> 
> We probably want to define some API that applications can use to invoke 
> the above but also IPv6 firewall traversal for regular IPv6

---

From: Norbert Bollow <[email-masked]>
Date: Fri, 21 Dec 2007 09:02:22 +0100 (CET)

> investigate that off-list if people would like us

I'm very much in favor of the topic of better variants of
NAT-PT being considered from all angles, and would personally
prefer on-list discussion of the details (or at least Cc: me
please :-)

Greetings,
Norbert.

-- 
Norbert Bollow <[email-masked]>                      http://Norbert.ch
President of the Swiss Internet User Group SIUG    http://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Dec 2007 14:03:42 +0100

> investigate that off-list if people would like us

One thing before we jump into specifics:

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. Then, the translator can trust all packets  
coming from the source address in question, or it can provide the host  
with a session key that can then be used in further shim signaling.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 28 Dec 2007 15:43:30 +0100

Hi Iljitsch,

El 28/12/2007, a las 14:03, Iljitsch van Beijnum escribió:

> 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. Then, the translator can trust  
> all packets coming from the source address in question, or it can  
> provide the host with a session key that can then be used in  
> further shim signaling.
>

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

In some cases, it is an important advantage and it is enough to have  
security techniques that do not require pre shared secrets and do not  
require infrastrucutre to their deployment. If this is possible, i  
would assume that this is preferred, since it would provide the  
required security without imposing the cost of the deployment of the  
infrastrucutre and the key provisioning

(FWIW, imho it would be possible to find such security approaches for  
SHANTI, but again, we are far from understanding the details of this)

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Dec 2007 19:05:15 +0100

On 28 dec 2007, at 15:43, marcelo bagnulo braun wrote:

>> simple user/password authentication.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Dec 2007 09:04:09 +1300

On 2007-12-29 07:05, Iljitsch van Beijnum wrote:
>>> 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 
>> 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
> 
> their ISP's network. 

s/is/may be/ ?

> Since it would obviously be problematic to accept 
> 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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 31 Dec 2007 14:19:42 +0100

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

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

> point in defending it against generic threats such as injection

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