Subject: [BEHAVE] version 01 of xlate

From: Xing Li <[email-masked]>
Date: Wed, 09 Sep 2009 17:19:11 +0800

Hi, All,

Based on Dave's comment, the discussions in the mailing list and the
meeting notes of IETF75, the authors have made the modifications and
uploaded the 01 version of the IP/ICMP Translation Algorithm. Here are
some editorial notes.

(1) Most of the grammar and spelling errors are corrected.
(2) Translating UDP over IPv4 (Sec. 2.2): Rewritten based on the
discussions on the mailing list.
(3) Transport-layer Header Translation (Sec. 2.5 and Sec 3.4): Reflected
the checksum neutral case.
(4) Translator sending ICMP error message: add the configuration
concerns in new sections (2.5 and 3.4).
(5) Translating ICMP extensions: add notes.
(6) Translating multicast packets: add notes.

Please review this version and send your comments and suggestions.

Regards,

xing

---

From: Chen Gang <[email-masked]>
Date: Tue, 15 Sep 2009 01:38:52 +0800

Hello Xing,

I have observed that you have also updated dual-stack implmentation,
IPv4-only and IPv6-only definition. For my understanding, these three terms
are basic adjectives and can be used to describe a host, which will appear
in several BEHAVE scenarios.

However, for the purpose of describing all cases of a host implmentation,
three adjectives is appearantly not enough. For example, IVI can be used in
scenario 1 and 2. Especially, in scenario 1, can I call IVI host located in
an IPv6 network as IPv6-only host or dual-stack host? No, since it has
double IVI appproach, in which the functions of the first IVI translator is
patched into the end systemthe, and it has IPv4-based application software
and IPv6/IPv4 enable system stack, IPv6 routing and address. Similar
examples will be appreared in many cases.

So, I suggest to add a new sort of adjective to deal with this problem. We
could define a general terms to cover various IPv4/IPv6 implementations.
Like following:

IPvX-adapted-IPvY implmentation: in this context, comprises an IPvX/IPvY
enabled end system stack, IPvX applications plus IPvY routing and address in
the network.  It implies that two application instances are capable of
communicating using IPvY by some sort of tranlations mechanisms to
accomodate IPvY environments.

The definition may need more works, but this sort of definition could fill
in a omission in current framework defintions.

Thanks for your attantion.

Best Regards

Gang

2009/9/9 Xing Li <[email-masked]>

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 14 Sep 2009 21:51:27 +0000

Reading a couple drafts, I was wondering about the security aspects of protocol translation. 

Take the IPv4 Internet to IPv6 network scenario. It differs from the "classic IPv4 NAT" in one great respect. While the IPv4 NAT mostly acts as the border between "the Internet" and "the private network", the v6-v4 NAT acts mostly as a bridge, not a border. The bridge can be accessed by the IPv4 Internet", as expected, but it could also be accessed from the IPv6 Internet, since we suppose connectivity between the IPv6 network and the IPv6 Internet. Accessibility from both sides clearly creates a different level of risk.

Or take the scenario of stateless translators sitting on the Internet, and accessible by pretty much everybody. These are essentially alternate paths for reaching IPv4 or IPv6 hosts. It seems to me that such translators will have many of the security properties of "anonymous relays", such as for example 6to4 gateways. 

I wonder how much of these security implications are already analyzed. I would very much like to take this analysis into consideration before the next iteration of the address format draft.

-- Christian Huitema

---

From: Chen Gang <[email-masked]>
Date: Tue, 15 Sep 2009 09:19:40 +0800

Hello Xing,

The comments may be attached to the wrong mail threads.
Sorry about that.
Please ignore it.

Best Regards

Gang

2009/9/15 Chen Gang <[email-masked]>

-- 
陈刚
[email-masked]

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 15 Sep 2009 07:54:14 +0200

Christian Huitema escribió:
> I wonder how much of these security implications are already analyzed.
There has been some analysis of security, but i am not aware that the 
threat analysis that you are suggesting has been systematically done and 
documented. I think it may be worthwhile doing it.

Among the things that have been discussed are:

There has been quite a bit of analysis to unerstand how to make DNS64 
work with DNSSEC.

On the translators themselves, there has been agreement that the 
translators should not forward packets coming from the internet towards 
the internet. e.g. that a translator shoudl not forward an IPv6 packet 
coming from an off site source addressed to an IPv6 represetnation of 
and IPv4 destiantion that is also off site (the motivation for this was 
to avoid providing free transit to the rest of the IPv4 internet)

Interaction with IPsec and TLS has also been (mildly) done.

Then there is all the filtering capabilities of the nats that has 
certainly been taken into consideration and all the discussion about 
tracking seq numbers in tcp is ongoing.

Regards, marcelo

>  I would very much like to take this analysis into consideration before the next iteration of the address format draft.
>
> -- Christian Huitema
>
>
>
>

---

From: Xing Li <[email-masked]>
Date: Tue, 15 Sep 2009 16:47:01 +0800

> Or take the scenario of stateless translators sitting on the Internet, and accessible by pretty much everybody. These are essentially alternate paths for reaching IPv4 or IPv6 hosts. It seems to me…

We have done some analysis for the stateless translator.

An IPv6 host in administrative domain B may send the packets to the 
stateless translator in administrative domain A. Since the source 
address of the packets is not a IPv4-mapped address in domain A, the 
translator will drop the packets.

xing

---

From: Christian Huitema <[email-masked]>
Date: Tue, 15 Sep 2009 14:11:14 +0000

> to avoid providing free transit to the rest of the IPv4 internet)

How does a translator what is in-site and what is off-site?

Besides, that is not completely sufficient. In some proposals, the IPv4 source address can be algorithmically derived from the IPv6 source address. In that case, an attacker can use the translation service to originate packets from pretty much any IPv4 source address. What is the protection?

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 15 Sep 2009 16:26:45 +0200

> How does a translator what is in-site and what is off-site?

right, i was just thinking about that,

So, in the statefull case, it is simple i think.

the border routers must not accept any incoming packet containing a 
destination address that contains the IPv6 prefix used to represent IPv4 
addresses.
So, if the WK prefix is used, the border router must filter all incoming 
packet containing the WK prefix in the destiantion address. The same if 
the LIR is used.

This works, cause none of the IPv6 addresses assigned to internal hosts 
contain the prefix used by the statefull translator.

With the stateless translator is more complicated, i think. since the 
same prefix can be used to make representation of external hosts and to 
assign internal hosts, then the filtenring needs to be done based on the 
embedded IPv4 address, which may require per IPv4 prefix filter 
configuration the border routers, which may be more complicated, but i 
think it is feasible...

> Besides, that is not completely sufficient. In some proposals, the IPv4 source address can be algorithmically derived from the IPv6 source address. In that case, an attacker can use the translation…
Right.
In the statefull case, this is not an issue since the source address is 
selected form the IPv4 pool of the nat64.
In the stateless case, we need some protection against that, i agree.
If we use the filters i mentioned above, based on the IPv4 prefix. then 
the off site attackers are prevented, agree?
So the problem is how can we deal with the on site attackers that want 
to spoof an address.
I think this is quite similar to the non natted situation. I mean, a 
host connected tot he internet can spoof any source address. The 
standard way to deal with this is to use ingress filters. So the ISP 
providing IPv4 access will need to configure ingress filters, so that 
the translator can only originate packets witht he source address that 
belong to the site.

So, summarizing, if we configure filters in border routers, we can 
prevent off site attackers, for both the state full and stateless 
translators (we need more fine grained filters for the stateless case, 
but still seems feasoble imho)

If we have these filters in place, on site attackers can still use the 
stateless translator to spoof source addresses. AFAICT, this is similar 
to what any IPv4 site can do today and this can be handled by the ISP of 
the site putting ingress filters in place.

Am i missing something?

Regards, marcelo

---

From: Christian Huitema <[email-masked]>
Date: Tue, 15 Sep 2009 14:42:37 +0000

> but still seems feasoble imho)

I really don't think we can assume more than basic filters in most site routers. The lower common denominator seems to be egress filtering. That is, sites will only accept incoming packets that are bound to the site's prefix, will normally not accept incoming packets whose source address belongs to that prefix, and will not allow outgoing packets whose source address does not belong to the site prefix.

> the site putting ingress filters in place.

I think we have to assume egress filtering, as described above, and not require specific filters. Certainly not filters that attempt to dissect the host part of an address. The technology we design should work with such basic filters, and should not add extra risks.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Sep 2009 16:53:06 +0200

> How does a translator what is in-site and what is off-site?

The same way any proxy or relay does: with a set of policy restriction  
rules.

> Besides, that is not completely sufficient. In some proposals, the  
> IPv4 source address can be algorithmically derived from the IPv6  
> source address. In that case, an attacker can use the translation  
> service to originate packets from pretty much any IPv4 source  
> address. What is the protection?

Since when are you protected against anything on the internet?

The case where an IPv4 host sets up a connection through a stateful  
NAT64 is similar to having a host on the outside set up a connection  
through a NAT44: if there is already some state, the packets will flow  
towards the internal/IPv6 host that created the state (case 1). If  
there is no state the translator doesn't know where to send the  
packets so they are dropped (case 2).

I see no reason for alarm in case 1 because presumably, the same IPv4  
host could have sent the same packet to the IPv6 host over IPv6 if the  
IPv4 host were dual stack. There is certainly no reason for alarm in  
case 2 because the packet don't get anywhere.

In case 1 it would be suboptimal if the packets flowed towards hosts  
that are not users of the NAT64 in question, but again, the same  
packets could have been sent by any IPv6 host. This is true for both  
the stateful and stateless case. IPv6 hosts wouldn't recognize the  
packets coming from the IPv4 world if a RIR prefix is used but the  
level of obfuscation is limited because the IPv4 address is still in  
there.

All in all, I don't see a problem as long as people don't treat any  
address ranges involved in the translation as "internal" or "trusted".  
(Which you really shouldn't do to begin with, addresses are easily  
faked in many circumstances.)

---

From: Zhen Cao <[email-masked]>
Date: Wed, 16 Sep 2009 10:09:49 +0800

Hi Xing,

According to the title 'IP/ICMP Translation' (no transport port
inside), my first impression about the document is that it should only
talks about stateless translation. Going over the document, i find the
description on stateful case nearly resort to the nat64 document.
Maybe i did not catch up with the work group concerns on working on
both stateless and stateful in one document?

Thanks,
Zhen

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Sep 2009 11:40:47 +0800

> both stateless and stateful in one document?

Please see the framework document, this was WG's decision.
(1) The title of RFC2765 is SIIT, but the title of this document is IIT (-:
(2) The details of the transport layer table maintenance is discussed in 
xlate-staful

xing

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Sep 2009 13:38:29 +0800

marcelo bagnulo braun 写道:
> destination address that contains the IPv6 prefix used to represent 
> IPv4 addresses.
> So, if the WK prefix is used, the border router must filter all 
> incoming packet containing the WK prefix in the destiantion address. 
> The same if the LIR is used.
>
> This works, cause none of the IPv6 addresses assigned to internal 
> hosts contain the prefix used by the statefull translator.
>
> same prefix can be used to make representation of external hosts and 
> to assign internal hosts, then the filtenring needs to be done based 
> on the embedded IPv4 address, which may require per IPv4 prefix filter 

the stateless translator can just simple drop the packets, if they are
not the IPv4-mapped source addresses in the administrative domain.

> In the statefull case, this is not an issue since the source address 
> is selected form the IPv4 pool of the nat64.
> If we use the filters i mentioned above, based on the IPv4 prefix. 
> then the off site attackers are prevented, agree?
> stateless translator to spoof source addresses. AFAICT, this is 
> similar to what any IPv4 site can do today and this can be handled by 
> the ISP of the site putting ingress filters in place.

(repeat) the stateless translator can just simple drop the packets, if 
they are
not the IPv4-mapped source addresses in the administrative domain.

xing

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Sep 2009 13:41:02 +0800

> faked in many circumstances.)

agree. xing

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 16 Sep 2009 09:27:16 +0200

Xing Li escribió:
>> Take the IPv4 Internet to IPv6 network scenario. It differs from the 
>> "classic IPv4 NAT" in one great respect. While the IPv4 NAT mostly 
>> acts as the border between "the Internet" and "the private network", 
>> the v6-v4 NAT acts mostly as a bridge, not a border. The bridge can 
>> be accessed by the IPv4 Internet", as expected, but it could also be 
>> accessed from the IPv6 Internet, since we suppose connectivity 
>> between the IPv6 network and the IPv6 Internet. Accessibility from 
>> both sides clearly creates a different level of risk.
>>
>> Or take the scenario of stateless translators sitting on the 
>> Internet, and accessible by pretty much everybody. These are 
>> essentially alternate paths for reaching IPv4 or IPv6 hosts. It seems 
>> to me that such translators will have many of the security properties 
>> of "anonymous relays", such as for example 6to4 gateways.   
>
right, this is another way of doing it.
the filtering can either be configured in the ingress routers of the 
site or in the translator itself.

Regards, marcelo

>
>
> xing
>
>> I wonder how much of these security implications are already 
>> analyzed. I would very much like to take this analysis into 
>> consideration before the next iteration of the address format draft.
>>
>> -- Christian Huitema
>>
>>
>>
>>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 16 Sep 2009 09:31:06 +0200

> I really don't think we can assume more than basic filters in most site routers. The lower common denominator seems to be egress filtering. That is, sites will only accept incoming packets that are…
So, this will solve the issue for the case the translator is using the 
WK prefix, correct?
The case of the LIR prefix would not be covered by this, since the LIR 
prefix is part of the site's prefix. Would xing's configuration of 
filters int he trnaslator itself would seem acceptable to you? I mean, 
in that case, the filters are configured in the translator itself, so 
that it doesn't forward any packet with a source address coming from a 
source address that doesn't belong to a local host i.e. the translator 
verifies the embedded IPv4 prefix.

Regards, marcelo

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Sep 2009 16:35:31 +0800

marcelo bagnulo braun 写道:
>>> essentially alternate paths for reaching IPv4 or IPv6 hosts. It 
>>> seems to me that such translators will have many of the security 
>>> properties of "anonymous relays", such as for example 6to4 gateways.   
>>

agree. xing

---

From: Christian Huitema <[email-masked]>
Date: Wed, 16 Sep 2009 13:56:09 +0000

> not the IPv4-mapped source addresses in the administrative domain.

But doesn't that require some amount of state?

Suppose the translator is managed by an ISP, for the service of its customers. The ISP network serves a large number of customers. In normal IPv6 practice, the ISP has assigned an IPv6 prefix to each of these customers. The ISP wants to provide a stable IPv4 address to some hosts of these customers, through a translation service. Obviously, the ISP cannot provide stable IPv4 addresses to each of his customers, because there are just not enough addresses.

If I understand correctly, this is a target deployment for the stateless translation service. The hosts to which stable IPv4 addresses have been assigned will be configured with an IPv4 translatable IPv4 address. The ISP translator will apply stateless translation when the outgoing address source is a translatable address, stateful translation when it is not. 

Let's assume that the customer site routers perform egress filtering, which is generally mandated by other security consideration. We have two possibilities then:

1) All source addresses, whether IPv4 translatable or not, must be assigned out of the IPv6 prefix assigned by the ISP to the customer site;

2) IPv6 translatable addresses use a special prefix, different from that of the customer site.

Frankly, I don't think that the second case is manageable. It implies special configuration in multiple routers, i.e. pushing and managing a lot of state information, which seems to defeat the whole idea of stateless translation. So, I will assume that we use the first variation, in which translatable addresses are generated out of the customer prefixes. This means that translatable addresses will only differ from the regular addresses by the structure of the host identifier.

If that is the case, if translatable addresses only differ from the regular addresses by the structure of the host identifier, how does the translator verify that customer A is not attempting to use an IPv4 address assigned to customer B?

-- Christian Huitema

---

From: Xing Li <[email-masked]>
Date: Thu, 17 Sep 2009 09:33:39 +0800

> If that is the case, if translatable addresses only differ from the regular addresses by the structure of the host identifier, how does the translator verify that customer A is not attempting to us…

how about configure uRPF in the stateless translator?  xing

---

From: Christian Huitema <[email-masked]>
Date: Thu, 17 Sep 2009 05:09:38 +0000

> > If that is the case, if translatable addresses only differ from the
> regular addresses by the structure of the host identifier, how does the
> translator verify that customer A is not attempting to use an IPv4
> address assigned to customer B?
> >
> 
> how about configure uRPF in the stateless translator?  Xing

uRPF is a form of ingress filtering. Of course you should enable that. But it is not sufficient. 

Suppose that customer A has an IPv6 translatable address of the form: <ISP-prefix>:<SubnetA>:<MagicA>:a.a.a.a, where a.a.a.a is the IPv4 address assigned by the ISP to A and "magicA" is the special sauce that distinguishes translatable addresses and enables checksum neutrality. Customer B normally uses addresses of the form <ISP-prefix>:<SubnetB>:<host-ID>. One of the hosts at customer B's site configures a host ID of the form <MagicB>:a.a.a.a -- using the appropriate magic, e.g. to match checksums. 

Customer B can send spoofed packets with the source address <ISP-prefix>:<SubnetB>:<MagicB>:a.a.a.a. These packets will be considered valid by egress filtering and uRPF checks, because they do indeed come from the right path for <ISP-prefix>:<SubnetB>. Will the translator forward these packets as originating from address <a.a.a.a>? If not, how does the translator decide that the packets from B are erroneous? What information does it use?

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Thu, 17 Sep 2009 03:06:50 -0300

> tracking seq numbers in tcp is ongoing.

FWIW, we had published an I-D
(http://www.gont.com.ar/drafts/nat-security/draft-gont-behave-nat-security-01.txt)
about security implications of NATs. The I-D has expired, but we are
working on a revision of it.

I presented this I-D back in November 2008 (in Minneapolis). Part of the
I-D is based on the assumption that you should rewrite some header
fields, as failure to do so might lead to interoperability problems that
were not present without the NAT (e.g., collisions of IP IDs if you
don't rewrite the IP ID, etc.). Unfortunately, it was my impression that
many participants ridiculed the discussion instead of thinking about the
issues we raised in our document. (Feedback is still appreciated!

To some extent, it all boils down to: from the external network, all
"connections" come from the same node. Therefore, from the external
network the header fields should look as if they the packets had really
been originated from the NAT (e.g., sequence numbers should look as if
they had been produced by RFC1948, etc.)

I have produced thorough discussion of TCP/IP security for UK CPNI:
TCP security:
http://www.cpni.gov.uk/Docs/tn-03-09-security-assessment-TCP.pdf
IP security: http://www.cpni.gov.uk/Docs/InternetProtocol.pdf

I still have to catch up with the new v6 work that is being produced....
but if you think I could be of help for any specific (existing or new)
document, please let me know.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Sep 2009 09:10:33 +0200

> Suppose that customer A has an IPv6 translatable address of the form: <ISP-prefix>:<SubnetA>:<MagicA>:a.a.a.a, where a.a.a.a is the IPv4 address assigned by the ISP to A and "magicA" is the special…
mmm, this is really not the configuration that i had in mind.
I mean, i always understood that we actually have a prefix to represent 
IPv4 addresses, as opposed to a magic token in the iid.

So, If the ISP is providing translation services, it will have a prefix 
that will be in the form of 
<ISP-prefix>:<subnet64>:<checksum-neutral-stuff>:a.a.a.a

So, the intra isp routing system will deliver the packets addressed to 
the <ISP-prefix>:<subnet64>::/n to the translator device.

I mean, if we use the magic token and all the IPv4 representations do 
not come from a common prefix, how does the routing system delivers the 
packets to to translator?

So, if we have this common prefix, the problem you mention is still 
present but in less degree i think.
An attacker in client B can spoof client A's source address. In order to 
cope with that, you need to be able to filter based on the IPv4 address, 
but you will need to route based on the IPv4 address in any case, to 
deliver the packets addressed to the IPv6 representation of the IPv4 
address assigned to  client A to the client A. So i think uRPF should 
still work.

Am i missing something?

regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 17 Sep 2009 10:34:42 +0200

> they had been produced by RFC1948, etc.)

Are you saying that a NAT64 should rewrite sequence numbers??

BTW, what happened last month in Holland?

Iljitsch

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 17 Sep 2009 21:44:41 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christian Huitema
> Sent: Wednesday, September 16, 2009 10:10 PM
> To: Xing Li
> Cc: Behave WG
> Subject: Re: [BEHAVE] Security implications of protocol translation
> 
> Suppose that customer A has an IPv6 translatable address of 
> the form: <ISP-prefix>:<SubnetA>:<MagicA>:a.a.a.a, where 
> a.a.a.a is the IPv4 address assigned by the ISP to A and 
> "magicA" is the special sauce that distinguishes translatable 
> addresses and enables checksum neutrality. Customer B 
> normally uses addresses of the form 
> <ISP-prefix>:<SubnetB>:<host-ID>. One of the hosts at 
> customer B's site configures a host ID of the form 
> <MagicB>:a.a.a.a -- using the appropriate magic, e.g. to 
> match checksums. 
> 
> Customer B can send spoofed packets with the source address 
> <ISP-prefix>:<SubnetB>:<MagicB>:a.a.a.a. These packets will 
> be considered valid by egress filtering and uRPF checks, 
> because they do indeed come from the right path for 
> <ISP-prefix>:<SubnetB>. Will the translator forward these 
> packets as originating from address <a.a.a.a>? If not, how 
> does the translator decide that the packets from B are 
> erroneous? What information does it use?

I understand what you're describing now.  Thanks.

The translator would need to validate the incoming packet
by examing the a.a.a.a address and deciding if the
<ISP-prefix>:<SubnetB> is correct.  The translator can
validate it by using its same algorithm for IPv4-to-
IPv6 packets; if the translator receives an IPv4 packet
with IPv4 address a.a.a.a, it will algorithmically
prepend <ISP-Prefix>:<SubnetA>:<MagicB> to it.  The
translator can notice that the arriving packet has
a different subnet, and drop it.  This is akin to the
translator doing a uRPF check on the source address
of the IPv6 packet:  "would I send an IPv4 packet
to this same IPv6 destination".

-d

---

From: Christian Huitema <[email-masked]>
Date: Fri, 18 Sep 2009 05:15:05 +0000

> to this same IPv6 destination".

Yes, that will work. But lets now compare this stateless option to the alternative, a stateful translator with some configuration. Specifically, suppose a stateful translator that manages a pool of IP addresses, and that is configured to "reserve" some addresses in that pool to specific IPv6 hosts. The configuration option would be something like "map a.a.a.a to <ISP-Prefix>:<SubnetA>:<HostId-A>."

Now, lets compare the amount of administrative overhead and routing overhead:

1) At the translator: In the stateless case, the NAT is programmed to map "a.a.a.a" to "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a"; In the stateful case, the NAT is programmed to map "a.a.a.a" to "<ISP-Prefix>:<SubnetA>:<HostID-A>". Basically the same cost.

2) At the host receiving the mapping: In the stateful case, the host manages exactly one address, "<ISP-Prefix>:<SubnetA>:<HostID-A>"; In the stateless case, the host has to be configured with two addresses, "<ISP-Prefix>:<SubnetA>:<HostID-A>" and "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a". Somewhat more complicated.

3) At intermediate routers: no configuration.

4) In the DNS: the host A has to be configured to publish the address a.a.a.a, in both cases.

>From an administrative point of view, it seems that the two solutions are almost equivalent, with a slightly lesser burden for the stateful scenario. The specification of the stateful is simpler, because it does not require any fancy addressing format, and can use whatever host ID structure is used in host A's subnet. In particular, A can use SEND.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Fri, 18 Sep 2009 05:29:53 +0000

> 1) At the translator: In the stateless case, the NAT is programmed to
> map "a.a.a.a" to "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a"; In the
> stateful case, the NAT is programmed to map "a.a.a.a" to "<ISP-
> Prefix>:<SubnetA>:<HostID-A>". Basically the same cost.
> 
> 
> 2) At the host receiving the mapping: In the stateful case, the host
> manages exactly one address, "<ISP-Prefix>:<SubnetA>:<HostID-A>"; In the
> stateless case, the host has to be configured with two addresses, "<ISP-
> Prefix>:<SubnetA>:<HostID-A>" and "<ISP-
> Prefix>:<SubnetA>:<MagicA>:a.a.a.a". Somewhat more complicated.
> 
> From an administrative point of view, it seems that the two solutions
> are almost equivalent, with a slightly lesser burden for the stateful
> scenario. The specification of the stateful is simpler, because it does
> not require any fancy addressing format, and can use whatever host ID
> structure is used in host A's subnet. In particular, A can use SEND.

To be fair, Xing's stateless proposal solves the security burden in a different way. Instead of using "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a", the mapped address would be <ISP-NAT-Prefix>:a.a.a.a:padding. The analysis of configuration requirements would be:

1) At the translator: The translator is configured to map all addresses in the mapped range (say a.a.a.0/n) to the <ISP-NAT-Prefix>:a.a.a.a:padding. The only required configuration is the range of address. There is no need to configure individual addresses.

2) At the host receiving the mapping: the host has to be configured with two addresses, "<ISP-
Prefix>:<SubnetA>:<HostID-A>" and "<ISP-NAT-Prefix>:a.a.a.a:padding". 
 
3) At intermediate routers: all intermediate routers between host A and the NAT need to install a route pointing the prefix "<ISP-NAT-Prefix>:a.a.a.a::"/n towards the host A. The last hop router, serving the domain to which A is attached, must be configured to relay these packets towards "<ISP-
Prefix>:<SubnetA>:<HostID-A>". All intermediate routers must implement some form of egress filtering, to prevent spoofing of packets by the local NAT.

This particular "stateless" solution does require a lesser administrative cost in the NAT. However, there is a tradeoff. The administrative cost in the intermediate routers is much higher. The solution trades a centralized management burden, in the NAT, for a distributed management burden, in the intermediate routers. I am not sure that this is the right tradeoff.

-- Christian Huitema

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 18 Sep 2009 07:44:29 +0200

Dan Wing escribió:
>>>> If that is the case, if translatable addresses only 
>>>>         
>> differ from the
>>     
>>> regular addresses by the structure of the host identifier, 
>>>       
>> how does the
>>     

the translator would then be less "stateless" since it has to have a 
binding between IPv4 address and IPv6 prefix which i understnad must be 
manually configured

Regards, marcelo

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Sep 2009 11:18:05 -0700

> From: Christian Huitema [mailto:[email-masked]] 
> Sent: Thursday, September 17, 2009 10:15 PM
> To: Dan Wing
> Cc: 'Behave WG'; 'Xing Li'
> Subject: RE: [BEHAVE] Security implications of protocol translation
> 
> Yes, that will work. But lets now compare this stateless 
> option to the alternative, a stateful translator with some 
> configuration. Specifically, suppose a stateful translator 
> that manages a pool of IP addresses, and that is configured 
> to "reserve" some addresses in that pool to specific IPv6 
> hosts. The configuration option would be something like "map 
> a.a.a.a to <ISP-Prefix>:<SubnetA>:<HostId-A>."
> 
> 1) At the translator: In the stateless case, the NAT is 
> programmed to map "a.a.a.a" to 
> "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a"; In the stateful 
> case, the NAT is programmed to map "a.a.a.a" to 
> "<ISP-Prefix>:<SubnetA>:<HostID-A>". Basically the same cost.
> 
> 2) At the host receiving the mapping: In the stateful case, 
> the host manages exactly one address, 
> "<ISP-Prefix>:<SubnetA>:<HostID-A>"; In the stateless case, 
> the host has to be configured with two addresses, 
> "<ISP-Prefix>:<SubnetA>:<HostID-A>" and 
> "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a". Somewhat more complicated.
> 
> From an administrative point of view, it seems that the two 
> solutions are almost equivalent, with a slightly lesser 
> burden for the stateful scenario. The specification of the 
> stateful is simpler, because it does not require any fancy 
> addressing format, and can use whatever host ID structure is 
> used in host A's subnet. In particular, A can use SEND.

Makes sense.  Thanks.

One note:  in this email, you appear to be using the term 
'stateful' to mean 'a translator with a configured 
1:1 mapping between an IPv6 address and an IPv4 address'.  
That use of 'stateful' is different from the use of 
'stateful' in draft-ietf-behave-v6v4-xlate-stateful-01.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Sep 2009 11:21:15 -0700

> Sent: Thursday, September 17, 2009 10:30 PM
> To: Dan Wing
> Cc: 'Xing Li'; 'Behave WG'
> programmed to
> > manages exactly one address, 
> "<ISP-Prefix>:<SubnetA>:<HostID-A>"; In the
> > 4) In the DNS: the host A has to be configured to publish 
> the address
> > a.a.a.a, in both cases.
> > 
> solutions
> To be fair, Xing's stateless proposal solves the security 
> burden in a different way. Instead of using 
> "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a", the mapped address 
> would be <ISP-NAT-Prefix>:a.a.a.a:padding. The analysis of 
> configuration requirements would be:
> 
> 1) At the translator: The translator is configured to map all 
> addresses in the mapped range (say a.a.a.0/n) to the 
> <ISP-NAT-Prefix>:a.a.a.a:padding. The only required 
> configuration is the range of address. There is no need to 
> configure individual addresses.
> 
> 3) At intermediate routers: all intermediate routers between 
> host A and the NAT need to install a route pointing the 
> prefix "<ISP-NAT-Prefix>:a.a.a.a::"/n towards the host A. The 
> last hop router, serving the domain to which A is attached, 
> must be configured to relay these packets towards "<ISP-
> Prefix>:<SubnetA>:<HostID-A>".

I'm not sure what you mean by "relay these packets towards" 
in the last sentence.  There are two routes at that last-hop 
router towards the host:  one route for the host's normal 
IPv6 address, <ISP-Prefix>:<SubnetA>:<HostID-A> and another 
route for the host's translatable IPv6 address, 
<ISP-NAT-Prefix>:a.a.a.a:padding.

> All intermediate routers must 
> implement some form of egress filtering, to prevent spoofing 
> of packets by the local NAT.
> 
> This particular "stateless" solution does require a lesser 
> administrative cost in the NAT. However, there is a tradeoff. 
> The administrative cost in the intermediate routers is much 
> higher. The solution trades a centralized management burden, 
> in the NAT, for a distributed management burden, in the 
> intermediate routers. I am not sure that this is the right tradeoff.

Yes, I agree in this case the NAT is reliant on properly
configured egress filtering close to the hosts.

-d

---

From: Xing Li <[email-masked]>
Date: Sat, 19 Sep 2009 09:44:34 +0800

> Customer B can send spoofed packets with the source address <ISP-prefix>:<SubnetB>:<MagicB>:a.a.a.a. These packets will be considered valid by egress filtering and uRPF checks, because they do inde…

(1) The address format of the stateless translation is 
PREFXI:IPv4:SUFFIX::/k, therefore the the issues raised in this mail do 
not exist. 
(2) Due to the features of the stateless translation, all the IPv4 and 
IPv6 security BCPs can be applied for the stateless translator on the 
IPv4 side and the IPv6 side, respectively.
(3) In addition, on the IPv6 network, there are no additional, 
translation-specific configurations required, since the translator can 
be treated as a router connecting to the IPv6 network. The same reason 
applied to the IPv4 side.

Regards,

xing and congxiao

---

From: Xing Li <[email-masked]>
Date: Sat, 19 Sep 2009 10:12:05 +0800

> To be fair, Xing's stateless proposal solves the security burden in a different way. Instead of using "<ISP-Prefix>:<SubnetA>:<MagicA>:a.a.a.a", the mapped address would be <ISP-NAT-Prefix>:a.a.a.a…

Thanks. The stateless translator (IVI) requires LIR and embed&zero-pad, 
which is discussed clearly in draft-xli-behave-v4v6-prefix-00, but 
unfortunately not very clear in draft-ietf-behave-address-format-00.txt.

> Prefix>:<SubnetA>:<HostID-A>" and "<ISP-NAT-Prefix>:a.a.a.a:padding". 

Not correct, the IPv6 host can configure ONE IPv6 address: That is 
LIR:IPv4:SUFFIX::/128. When this host communicates with IPv6 Internet, 
the IPv6 routing system will direct the packets to the right 
destination. When this host communicates with IPv4 Internet, the IPv6 
routing system will direct the packets to the stateless translator, then 
the IPv6 packets will be converted into the IPv4 packets and sent to the 
right destination via IPv4 routing system.

BTW, please also note that "<ISP-NAT-Prefix>:a.a.a.a:padding" is a 
special subnet of "<ISP-Prefix>:<SubnetA>" . Then you will see why the 
stateless translator behaves just like an ordinary router and all the 
security BCPs can be applied to it.

> Prefix>:<SubnetA>:<HostID-A>". All intermediate routers must implement some form of egress filtering, to prevent spoofing of packets by the local NAT.

Not true, see above. There is no special case here for the other 
routers, since the stateless translator behaves as an ordinary router, 
all the routes in this IPv6 network are ordinary routes.

> 4) In the DNS: the host A has to be configured to publish the address a.a.a.a, in both cases.

The DNS resolver needs to know the LIR. And the IPv6 host has A record 
a.a.a.a and AAAA record LIR:a.a.a.a:SUFIX:: in the Authority DNS.

> This particular "stateless" solution does require a lesser administrative cost in the NAT. However, there is a tradeoff. The administrative cost in the intermediate routers is much higher. The solu…

Not correct, see above for reasons.

Regards,

xing

---

From: Xing Li <[email-masked]>
Date: Sat, 19 Sep 2009 10:15:24 +0800

marcelo bagnulo braun 写道:
>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Christian Huitema
>>> Suppose that customer A has an IPv6 translatable address of the 
>>> form: <ISP-prefix>:<SubnetA>:<MagicA>:a.a.a.a, where a.a.a.a is the 
>>> IPv4 address assigned by the ISP to A and "magicA" is the special 
>>> sauce that distinguishes translatable addresses and enables checksum 
>>> neutrality. Customer B normally uses addresses of the form 
>>> <ISP-prefix>:<SubnetB>:<host-ID>. One of the hosts at customer B's 
>>> site configures a host ID of the form <MagicB>:a.a.a.a -- using the 
>>> appropriate magic, e.g. to match checksums.
>>> <ISP-prefix>:<SubnetB>:<MagicB>:a.a.a.a. These packets will be 
>>> considered valid by egress filtering and uRPF checks, because they 
>>> do indeed come from the right path for <ISP-prefix>:<SubnetB>. Will 
>>> the translator forward these packets as originating from address 
>>> <a.a.a.a>? If not, how does the translator decide that the packets 
>>> from B are erroneous? What information does it use?
>>
> binding between IPv4 address and IPv6 prefix which i understnad must 
> be manually configured

No.
(1) The uRPF can be configured.
(2) The stateless translator maps the IPv6 source address to the IPv4 
address, if it is not translatable address, the translator will drop it.

regards,

xing

---

From: Christian Huitema <[email-masked]>
Date: Sun, 20 Sep 2009 02:13:35 +0000

> right destination via IPv4 routing system.

I understand what you are proposing, but I do not believe that we have WG consensus there. What you are proposing amounts to entirely rework the way IPv6 addresses are configured, in order to better support stateless address configuration. That may be a tradeoff that the WG wants to support, but it will require some very explicit decision.

Your proposal differs from the current practice in multiple ways. Most noticeably, you propose to replace the current address format (64 bit subnet + 64 bit host ID) by a new format (ISP prefix + 32 bit IPv4 address + padding). There is a substantial list of standards that will have to be modified if we want to replace the current practice by your proposal. Of course, we will have to replace the current address configuration procedures. But that is not all.

For example, in order to make ND work, we will have to map IPv6 subnets to IPv4 subnets, and make sure that the IPv6 subnet is composed of the ISP prefix and the "subnet" part of the IPv4 address, and make sure that the "translatable" hosts receive addresses in the appropriate IPv4 subnet. Then, we will have to either make sure that the new prefix (ISP + IPv4 subnet) always fall on a 64 bit boundary, or, if that cannot be achieved, modify existing implementations to make sure that they work with arbitrary subnet boundaries. 

I do not believe that we have WG consensus to specify that. We might obtain this consensus if the benefits of easy translation were such that they overcome the burden of modifying standards and implementations. But, frankly, I doubt it.

But my biggest problem is that the proposal is only economical if we can assign a unique IPv4 address to every host. If we cannot, then network managers will have to run two parallel addressing schemes. Nodes on the same links will end up with different address prefixes depending whether they have a "translatable" address or not. Routers will have to manage two parallel set of tables. 

At the same time, I believe we can obtain the benefit of stateless mapping without having to change existing address management practices. The main benefit of your proposal is to simplify the management of stateless translators, who can algorithmically extract the IPv4 source address from the incoming IPv6 source address. But the translators could just as well obtain the IPv4 source address by a look up in a table of "translatable" addresses. Granted, we will need to pass that table to all stateless translators. But I believe that organizing the distribution of this table is much simpler than modifying the existing standards and practices for address configuration, neighbor discovery, or subnet management.

-- Christian Huitema

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 21 Sep 2009 10:56:28 -0700

> At the same time, I believe we can obtain the benefit of stateless mapping without having to change existing address management practices. The main benefit of your proposal is to simplify the manag…

I agree with Christian. The complications with basic functions like ND
is at risk in this stateless model and the requirement for unique IPv4
addresses will not be easy to meet.

-- Cameron Byrne

---

From: Xing Li <[email-masked]>
Date: Tue, 22 Sep 2009 11:01:32 +0800

>> I understand what you are proposing, but I do not believe that we have WG consensus there. What you are proposing amounts to entirely rework the way IPv6 addresses are configured, in order to bett…

No, actually we are doing DHCPv6 configuration or manual configuration 
for the IPv4-translatable addresses. Please note that people usually 
configure the server address manually. Examples are

% host ipv6.google.com
ipv6.google.com is an alias for ipv6.l.google.com.
ipv6.l.google.com has IPv6 address 2001:4860:c004::68

% host ipv6.apnic.net
ipv6.apnic.net has address 202.12.29.122
ipv6.apnic.net has IPv6 address 2001:dc0:2001:b:4608::115

The IPv4-translatable address configuration for the IPv6 host is just 
like this, via DHCPv6 or manual configurations.
>> Your proposal differs from the current practice in multiple ways. Most noticeably, you propose to replace the current address format (64 bit subnet + 64 bit host ID) by a new format (ISP prefix +…

We don't think so, it is just manual configuration or DHCPv6 for the 
host address configuration.

>> For example, in order to make ND work, we will have to map IPv6 subnets to IPv4 subnets, and make sure that the IPv6 subnet is composed of the ISP prefix and the "subnet" part of the IPv4 address,…

See above. In addition,

(1) Since the IPv6 addresses assigned to the IPv6 hosts are a subset of 
the IPv6 addresses and explicitly define by the NSP prefix and the IPv4 
addresses, the stateless auto-configuration cannot be used and the 
DHCPv6 or manual configuration should be used. We have been using 
dibbler to assign IVI addresses (IPv4-translatable) to the Windows XP 
and Linux hosts without problem.

(2) We have defined a new address format for IVI. In the new format, the 
meaning of u-bit (bit 71) can be kept.

>> But my biggest problem is that the proposal is only economical if we can assign a unique IPv4 address to every host. If we cannot, then network managers will have to run two parallel addressing sc…

We have been working on a new draft, which we call "IPv4 address sharing 
stateless translation", in this scheme, a single IPv4 address can be 
shared by a number of IPv6 hosts.

>> At the same time, I believe we can obtain the benefit of stateless mapping without having to change existing address management practices. The main benefit of your proposal is to simplify the mana…

Yes, this is another alternative. But it also introduces some kind of 
states.
> addresses will not be easy to meet.
We need to handle ND carefully, same as DHCPv6.

regards,

xing