Subject: [BEHAVE] draft-mrw-behave-nat66-00.txt is now posted

From: Margaret Wasserman <[email-masked]>
Date: Mon, 27 Oct 2008 14:59:30 -0400

I have posted a NAT66 draft, so that we can have a better-grounded  
discussion of whether it makes sense to include NAT66 as a work item  
in the behave charter.  The draft can be found at the following URL:

http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt

Feedback would be greatly appreciated!

Margaret

> A new version of I-D, draft-mrw-behave-nat66-00.txt has been  
> successfuly submitted by Margaret Wasserman and posted to the IETF  
> repository.
>
> Filename:	 draft-mrw-behave-nat66
> Revision:	 00
> Title:		 IPv6-to-IPv6 Network Address Translation (NAT66)
> Creation_date:	 2008-10-27
> WG ID:		 Independent Submission
> Number_of_pages: 13
>
> Abstract:
> This document describes a stateless, transport-agnostic IPv6-to-IPv6
> Network Address Translation (NAT66) function that provides the
> address independence benefit associated with IPv4-to-IPv4 NAT (NAT44)
> while minimizing, but not completely eliminating, the problems
> associated with NAT44.
>
> This document also describes an address mapping option for NAT66 that
> offers the topology hiding benefit associated with NAT44 at the cost
> of additional state in the NAT66 device.

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

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 28 Oct 2008 09:22:44 -0400

Shortly after posting this, I realized that I made an error in
transcribing the math in section 5.1.1.

The draft says:

 >  The one's complement checksum of FD01:0203:0405 is 0xFCF5.  The  
one's
 >  complement checksum of 2001:0DB8:0001 is 0xD245.  Using one's
 >  complement math, 0xD245 - 0xFCF5 = 0xD54F. The subnet mask in the
 >  original packet is 0x0001.  Using one's complement math, 0x0001 +
 >  0xD54F = 0xD550.
 >
 >  So, the value D54F is written in the 16-bit subnet mask area,
 >  resulting in a mapped external address of 2001:0DB8:0001:D54F::0001.
 >
 >  When a response packet is received, it will contain the destination
 >  address 2001:0DB8:0001:D54F::0001, which will be mapped using the
 >  same mapping algorithm, back to FD01:0203:0405:0000::0001.

The first paragraph is correct, and the subnet mask should be set to
0xD54F + 0x0001, which equals 0xD54F.

In the second and third paragraphs, all three instances of D54F should  
be
replaced with D550.

I have corrected this in my -01 edit buffer.  I'll wait to see if I  
get any other
feedback this week, and if I have enough changes to make it worthwhile,
I'll post an update before the final draft deadline.

I would appreciate your feedback on the draft, as well as your opinions
about whether a NAT66 effort should be chartered in the behave WG.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 28 Oct 2008 10:25:40 -0400

For some reason, I just can't get this right...  :-)

> 0xD54F + 0x0001, which equals 0xD54F.

0xD54F + 1 = 0xD550, of course!

Anyway, there is no problem with the algorithm described, as far as I  
know, just with my ability to type in accurate calculations.

Margaret

---

From: Ed Jankiewicz <[email-masked]>
Date: Tue, 28 Oct 2008 15:57:26 -0400

Seems a reasonable draft, lives up to its abstract.  A couple comments.

1.  Introduction:  "interference with security mechanisms that involve 
end-to-end encryption of IP headers" I think that's not exactly right, 
as AH authentication is not end-to-end encryption, but won't work with 
any NAT that modifies the protected header fields, including IP 
addresses.  ESP would work through NAT66, allowing end-to-end encryption 
but not authentication.  Unless I'm missing something.

2.  Motivation:  subtle difference between "not recommending the use of 
NAT" and "recommending not having NAT66" but overall the draft seems to 
lean towards "not recommending" rather than "recommending not".  Hence 
the definition of a "safer" way of doing it if you must?   This explains 
the motivation for the draft, but the draft does not give convincing 
motivation FOR using NAT66.  It seems like having both a ULA and global 
unicast address on an interface allows use of ULA for local traffic and 
the global otherwise.  Topology hiding is already provided in RFC 4864.  
I'm not invoking the third rail, but I think the draft should provide 
some good reasons or scenarios when use of NAT66 would be a reasonable 
alternative. 

3.  Security Considerations:  the risk is no worse than native IPv6 
without a firewall, but it is good to point out that the NAT44 "security 
side effect" doesn't carry over to NAT66.

Ed J.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 28 Oct 2008 16:05:41 -0400

Thanks, Ed!

Your feedback is helpful, and I will attempt to address your comments  
in the next version of the draft.

Margaret

On Oct 28, 2008, at 3:57 PM, Ed Jankiewicz wrote:

> 1.  Introduction:  "interference with security mechanisms that  
> involve end-to-end encryption of IP headers" I think that's not  
> exactly right, as AH authentication is not end-to-end encryption,  
> but won't work with any NAT that modifies the protected header  
> fields, including IP addresses.  ESP would work through NAT66,  
> allowing end-to-end encryption but not authentication.  Unless I'm  
> missing something.
>
> 2.  Motivation:  subtle difference between "not recommending the use  
> of NAT" and "recommending not having NAT66" but overall the draft  
> seems to lean towards "not recommending" rather than "recommending  
> not".  Hence the definition of a "safer" way of doing it if you  
> must?   This explains the motivation for the draft, but the draft  
> does not give convincing motivation FOR using NAT66.  It seems like  
> having both a ULA and global unicast address on an interface allows  
> use of ULA for local traffic and the global otherwise.  Topology  
> hiding is already provided in RFC 4864.  I'm not invoking the third  
> rail, but I think the draft should provide some good reasons or  
> scenarios when use of NAT66 would be a reasonable alternative.
> without a firewall, but it is good to point out that the NAT44  
> "security side effect" doesn't carry over to NAT66.
>
> Ed J.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 29 Oct 2008 01:17:06 -0400

Actually, let me respond to one of your points here:

On Oct 28, 2008, at 4:05 PM, Margaret Wasserman wrote:
>> 2.  Motivation:  subtle difference between "not recommending the  
>> use of NAT" and "recommending not having NAT66" but overall the  
>> draft seems to lean towards "not recommending" rather than  
>> "recommending not".  Hence the definition of a "safer" way of doing  
>> it if you must?

Yes, that is the point I am trying to make.  I've tried to strike a  
balance between making it clear that we don't recommend NAT and  
pointing to alternatives vs. making to clear that we understand that  
there are some reasons why people will choose to use NAT66 and  
offering a way to implement one that is less harmful and more  
functional than traditional NAT44.  Maybe I didn't strike that balance  
correctly...

>>  This explains the motivation for the draft, but the draft does not  
>> give convincing motivation FOR using NAT66.  It seems like having  
>> both a ULA and global unicast address on an interface allows use of  
>> ULA for local traffic and the global otherwise.

No, not so.  The use of both ULAs and global addresses does allow  
local traffic to use local addresses (in most cases) and external  
traffic to use external addresses.  However, it still requires that  
the external, provider-allocated addresses be configured throughout  
the network (in routers, in DHCP servers, in security ACLs, etc.), and  
that they be exposed to external nodes in the DNS, etc.  It also  
requires that every node in the network make the "right" choice about  
whether to use a local or global address for communication with both  
local and global nodes, something that we've struggled with how to do  
correctly in IPv6.

There are many enterprise networks that have plenty of IPv4 addresses  
available to them who choose to use NAT44, anyway.  When we've talked  
to these people about why they use NAT44, they have pointed to several  
different reasons, the four most common/compelling of which are:  (1)  
provider independent internal addressing -- no need to renumber to  
change ISP, ISP can't force renumbering even by going out of business,  
etc. (2)  topology hiding -- a desire to hide their internal network  
structure/subnetting plan from the outside world, (3) site multihoming  
-- they want to connect their site to two different providers without  
having to get those providers to coordinate on using a single global  
address prefix for their site, without the complexity of using  
multiple address prefixes internally, and/or (4) "security" --  
referring to the fact that a NAT44 box effectively blocks inbound  
connections.

RFC4864 talks about all of the "benefits" of NAT and how they can be  
obtained in IPv6.  However, it contains no real answer for (1)  
provider independent addressing, which is an even wider issue in IPv6,  
as many sites that have their own IPv4 addresses today will not be  
able to get their own global IPv6 address prefix.  It says "use ULAs"  
as though that solves the independent addressing issue, when it  
doesn't, as every node that wishes to communicate on the global  
Internet will also need a global unicast address.  The answers for (2)  
topology hiding are more fleshed out, but there is no reason to  
believe that administrators will prefer them to NAT.  The solutions  
rely on RFC 3041, which is not widely implemented and, even if it  
were, only solves a small part of the problem, because it only works  
for connections where the internal nodes initiates the connection, and  
it is only used when an application requests an RFC 3041 address,  
which virtually no applications do today.  Randomizing subnets does  
not help at all if the knowledge of the internal structure is gathered  
by observing traffic entering and exiting the site.  There are also  
some other methods discussed in the document, but most or all of those  
methods are just as possible in IPv4, and they have not been preferred  
over NAT44 by people who actually deploy enterprise networks.  
Regarding (3) site multihoming, RFC 4864 makes it clear that IPv6 has  
no real solution to this problem.  Work is underway on a shim6-based  
solution, but shim6 will require changes in every host, and it is not  
yet clear that it will be widely implemented or deployed.  I think we  
all know that NAT doesn't provide any real "security", but it does  
provide something similar to an inflexible stateful firewall  
function.  This behavior is important enough to enterprise  
administrators that people who produce IPv6 routers have pretty much  
been forced to include a stateful firewall in their products that  
defaults to essentially the same behavior as a NAT44 device.  That  
seems to solve the problem pretty well, so I don't think it is  
necessary that NAT66 have the same firewall-like side effect as NAT44.

>>  Topology hiding is already provided in RFC 4864.  I'm not invoking  
>> the third rail, but I think the draft should provide some good  
>> reasons or scenarios when use of NAT66 would be a reasonable  
>> alternative.

Do the above arguments make sense to you?   I didn't include this type  
of text in the draft, because I don't want to get into an argument  
about whether this draft or RFC4864 is more correct.  RFC4864 explains  
how you can do a number of things without deploying NAT66, and you  
can.  What it doesn't explain is why people will take those steps to  
avoid deploying NAT66, when they haven't been willing to take some of  
the same steps to avoid deploying NAT44.  In fact, most of the people  
I know who run NAT44-based networks in their homes or enterprises are  
quite happy with them.

This is a long story that tries to explain why I think people _will_  
deploy NAT66, even though we'd prefer that they didn't.  Given that I  
believe that it is inevitable that NAT66 will be widely deployed, I'd  
like to try to get the folks who implement it to do it in a way that  
has fewer problems and less negative impact on the IPv6 Internet than  
NAT44 does.

How much of this does it make sense to include in the draft?

Margaret

---

From: Ed Jankiewicz <[email-masked]>
Date: Wed, 29 Oct 2008 18:00:17 -0400

thanks for your thoughtful response.  I guess I could have refreshed on 
the details of 4864 before chiming in.  In general, I support this 
document and see it as a necessary evil, and agree that it should be 
complementary to 4864, not replacing or refuting it.  Nothing to be 
gained by ignoring and forbidding the use of IPv6 NAT if it's going to 
happen anyway.

See some follow-up in-line.

Margaret Wasserman wrote:
>>> not".  Hence the definition of a "safer" way of doing it if you must?
>
Perhaps be more explicit - replace the first sentence of the second 
paragraph of Motivations with three points:  The IETF does not recommend 
the use of NAT in IPv6 networks [is there a citation?]. Some deployments 
will choose to use an IPv6 NAT as an alternative or complement to the 
methods defined in [RFC 4864].  It is important to understand the impact 
of this decision and the intention of this document is to  provided 
guidance to the design and deployment of NAT66 to avoid the drawbacks of 
NAT44.
> How much of this does it make sense to include in the draft?
There is no need to regurgitate large parts of RFC 4864 in the draft - 
but an annotated list of the recommendations made in 4864, identifying 
the relationship of the two documents as complementary, indicating where 
4864 provides the best approach, where this document provides an 
alternative to what is recommended there, and especially where this 
document fills gaps in 4864 - that would be sufficient.  Definitely less 
detail than the above, but guidance to the reader on using the two docs 
in parallel and choosing appropriate solution for their deployment.  
Don't absolve the reader of responsibility to read and understand 4864.  
One way to do it would be a table similar to the one in the intro to 
4864.  Either way, just enough to provide the context.  It's definitely 
more important to focus on the new material.

Thanks again.  I will plow through RFC 4864 again and see if I can come 
up with any more specific comments.

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  [email-masked]