Re: (ngtrans) NAT-PT -05 INput

[Jim Bound <[e-mail]>]

Hi George,

>> 1.  You state NAT-PT supports end-to-end.  That is simply not the case
>> or you need to define end-to-end in terms of NAT.  This I believe could
>> be misleading to the market to see the word end-to-end.  Also I think
>> the way to state this is end-2-end in the nomenclature.
>> See: draft-carpenter-transparency-00.txt as I too define e2e and NAT-PT
>> is far from transparent.  Also text I sent on deployment list as to what
>> constitutes e2e IMO.  

>Jim, I think NAT-PT has one of the most complete and sincere
>"applicability statements" and "security considerations" sections plus
>section 6 on "NAT-PT Limitations". I find hard to beleive that anyone will
>missunderstand what NAT-PT is.

I agree.  But NAT-PT is not end-to-end as you call it.  I think saying
it is wrong.

>> 
>> 2.  The spec needs a lot of editing.  It appears the use of "articles"
>> is missing in many sentences "a", "an", "the".  But this is editing.
>> 
>
>Yes and Margaret is taking care of that, although I am getting a bit weary
>of the fact that NAT-PT is getting special treatment on the "editing"
>front, I am waiting to see the same treatment on other drafts... 

I think they all need editing.  BIS and XLATOR needs work too.
Whick I will be sending input on soon.

One thing I have noticed that is important.  In the English language the
use of "articles" 'a, an, the' are pretty much not correct in specs by
persons to whom this is not their native language.  I even mess it up
myself often.  They are important to be placed correctly because it can
change the meaing of a sentence.

>> 3.  Under: 3.1 NAT-PT Outgoing Sessions (IPv6 to IPv4)
>> 
>>       If the outgoing packet is not a session initialisation packet, the
>>      NAT-PT  SHOULD  already  have  stored some state about the related
>>      session, including assigned IPv4 address and cached parameters for
>>       the  translation.   If this state does not exist the packet SHOULD
>>      be silently discarded.
>> 
>> What if it is a UDP session?  Something should be stated if its not a
>> TCP SYN start.
>> 
>
>There is no deterministic way to know the start of UDP sessions.
>draft-ietf-nat-terminology-01.txt at section "2.1.3. Start of session for
>TCP, UDP and others" is talking about it and we could add this here as
>well. 
>Suresh, do you agree?

As the all work in NAT does not apply to IPv6 then I think NAT-PT needs
its own terminology section for NGTRANS.

I think that UDP cannot be identified needs to be stated in the
applicability statements.

So how are you caputuring a DNS UDP packet?


>> 4.  Use of PREFIX::1.2.3.4 on incoming and outgoing sessions.  
>> 
>> You don't ever state how this PREFIX is assigned to an IPv6 node on the
>>> V6 domain behind the NAT-PT.  But more importantly how it may be routed
>> on the V6 Network?  How the PREFIX plays in the topology.
>> 
>> FRom section 3.2:    
>> 
>>       Say the IPv6 Host A wanted to set up a TCP session with  the  IPv4
>>      Host  C.
>> 
>>       Host A creates a packet with:
>> 
>>       Source Address, SA=FEDC:BA98::7654:3210 , source TCP port  =  3017
>>      and Destination Address, DA = PREFIX::132.146.243.30,  destination
>>      TCP port = 23.
>> 
>> How did Host A "know" the PREFIX for the DA?

>In section 4.2.1 DNS ALG, it clearly states that the PREFIX:: is added by
>the NAT-PT during the translation of a DNS A record to a AAAA record. This
>way PREFIX:: is part of the IPv6 routing and configured by the network
>administrator and there is no constrain for the hosts to know about
>"translatable addresses" ala SIIT, although these could be used as well.

OK I could have misread it.  So are you saying that no node in NAT-PT
scenario EVER sends a packet from its interfaces with
PREFIX::ipv4.address.type.NAT-PT.  That it is always done by the NAT-PT
router?  

If so OK.

>>> 5.  Under section 4 IPv4 Address Assignment
>>> 
>>> 4.1 V4 Address assignment for outgoing connections
>>> 
>>>       Outbound session start is based on identifying the first packet of
>>>      a session. For ex: SYN, !ACK for TCP sessions.
>> 
>> Please reference UDP too or some example?
>> 
>>       V6 hosts learn the address of V4 hosts from the DNS server in  the
>>      V4  domain or the DNS server internal to the V6 network. We recom-
>>      mend that DNS servers internal to V6 maintain mapping of names  to
>>      IP  V6  addresses  for  internal  hosts and possibly some external
>>      hosts.  External DNS servers in the V4 domain maintain  name  map-
>>      ping for external hosts (i.e., V4 hosts) alone.
>> 
>> Why is this different than what DNS already does?  I don't see why your
>> saying this text in the spec and your recommendation is the norm?  It
>> appears you are stating the obvious?  So I am missing something in the
>> text above can you tell us why you say this above?
>> 

>What we try to make sure here is that DNS entries for IPv6 ONLY hosts
>should not be retained by IPv4 ONLY DNS servers and vice versa. Note that
>this can happen because of temporary assignement of IPv4 addresses to IPv6
>hosts (and vice versa). So, that is why we also say that DNS replies that
>have been translated by NAT-PT should not be cached.

OK just say that?  I don't think you need all the other words in the
spec.  This is standard DNS stuff.

>>       4.2.1 DNS Application Layer Gateway (ALG) support
>> 
>>          In figure 2 above, when Host C name resolver makes a name  look
>>         up  request  for  Host A, the lookup query is redirected to the
>>         DNS server on the V6 network. Considering that NAT-PT is resid-
>>         ing   on the border router between V4 and V6 networks, this re-
>>         quest datagram would traverse through the  NAT-PT  router.  The
>>         DNS  ALG on NAT-PT  would modify  the DNS Queries going into V6
>>          domain as follows:
>> 
>> Do you want to ref DNS-ALG?  Also in the first sentenced I think you
>> want to say "directed" not redirected because this is what DNS does as
>> the norm. 
>
>Should be "directed".

>>  NAT-PT is intercepting all DNS queries, but what else?

>Sorry, what else are you thinking about? DNS-ALG will intercept DNS
>queries and DNS replies that cross NAT-PT.

Just that DNS is the only protocol being intercepted?

What about when the packet is fragmented DNS UDP?  

>> This
>> is why I ask if you want to reference another spec that supports an IPv6
>> DNS-ALG example?   The one for NAT now only supports IPv4 in the NAT WG
>> maybe we need one for IPv6 too, so this WG can parse that as DNS for
>> NAT-PT is a pretty big part and will affect users normal DNS processing
>> and all the configuration possible with Firewalls etc.

>The DNS-ALG will NOT affect "users normal DNS processing" apart from the
>stated fact that DNSSEC will not work.

Performance is part of "Normal Processing" by my customers definitions,
sorry for not making that clear.  Intercepting and munging DNS packets
will cost.

>> Also I think you need to address A6 and the binary labels for the
>> reverse records.  This will complicate and increase the DNS packet 
>> intercepting at the NAT-PT and should be discussed later as a "pain" to 
>> using this mechanism or appropriate wording.  
>> 

>Yes, I have been thinking about it. In principle you are correct that A6
>records are more "painful" for the DNS-ALG but the operation does not
>change. We can add A6 records in the text, although I hope by the time A6
>records are available IPv6 will have taken over the world and NAT-PT is
>not going to be needed any more :) ...day dreaming... ;)

They will be a pain for all proposals.  

NAT-PT will be needed for all transition for sometime.
Which is why I am trying to review it as best I can.

>>          In the opposite direction, when DNS response traverse from  the
>>         DNS  server  on  V6 network to V4 host, the DNS-ALG once  again
>>         traps the DNS packet and would:
>> 
>>             a)  Translate  DNS  responses  for  "AAAA"  records into 'A'
>>            records,
>>             b) Replace the V6 address sent by the V6 DNS server with the
>>            V4 address internally assigned by the NAT-PT router.
>> 
>> Here A6 type records may be requested multiple times by a client v6
>> resolver as it tries to find the top level DNAME zone.  This complicates
>> the query at the NAT-PT and could imply state for the DNS processing
>> within the NAT-PT for processing.  Also if IPv4 comes back the V6 node
>> now must deal with that in the V6 resolver code and this should be
>> discussed in this spec or in an updated DNS-ALG NAT spec.
>> 

>Again it is just more precessing but the principle of operation still
>works. We can add a note about that though...

What I was worried about here was the fact that if UDP is used how does
a NAT type box keep track of the multiple messages that may occur
because of A6 records from the resolver?  For starters?

>>          If a V4 address is not previously assigned  to  this  V6  host,
>>         NAT-PT would assign it this time. The TTL values on all DNS re-
>>         source records (RRs) passing through NAT-PT would be set to  0.
>> 
>> Is the NAT-PT dynamically updating the DNS or just keeping state in the
>> NAT-PT.  If using dynamic updates then this is scary because NAT-PT
>> cannot support DNSSEC and this problem should be stated in the spec if
>> dynamic updates to DNS MUST be supported without security.  I gave you
>> folks this input on the existing DNS-ALG for IPv4 privately as input too
>> last week.  

>At the moment that draft does not say anythink about dynamic DNS. This is
>just state on the NAT-PT! Remember that no DNS server is aware of
>DNS-ALG's existence--> that is why DNSSEC does not work across a 
>NAT-PT!

Hmmm.  OK.  So NAT-PT changes the content of DNS queries and responses
btw the two parties?  

Do we need to specify more than just DNSSEC don't work but that this is
a serious "trust the person in the middle" issue?

>>          This  technique  is  also  useful for outgoing communication as
>>         well. We saw that a v6host that needs to communicate with  a v4
>>         hosts needs to use a specific prefix (PREFIX::) in front of the
>>         IPv4 address of the v4host. The above technique allows the  use
>>         of this prefix without any configuration in the hosts. E.g.: In
>>         Figure 2, Host-A makes a name look-up on the  Host-C.  The  DNS
>>         query  goes  to  the v6 DNS server and from there to the v4 DNS
>>         server outside the v6 stub domain after it has been  translated
>>         by  the  NAT-PT.  The  reply follows the same route but now the
>>         NAT-PT translates the reply adding the appropriate prefix.  So,
>>         if the reply is:
>> 
>>             HostC    A     132.146.243.30, it is translated to
>>             HostC   AAAA   PREFIX::132.146.243.30
>> 
>> Again how does a user determine the PREFIX to configure?  Some examples
>> and discussion is needed IMO.  

>The start of the paragraph that you quote states exactly what happens. As
>I said before PREFIX:: is configuration on the NAT-PT.

I am fine with the explanations for Destination Address in the IP Header
my concern is the Source Address from a V6 Host ever being PREFIX::....
because then the Host would have to know that PREFIX.  But I think your
telling me this can never happen.

We might want to just make sure this is all clear, but I will read it
again.

>> And if it is an A6 RECORD what is the affect as they are distributed
>> unlike AAAA records.  You folks need to address A6 Records.
> 
>> You should state that the PREFIX will not be an IPv4 Mapped or IPv4
>> Compatible Address too.

>PREFIX can be anything the administrator decides but it is bad
>idea to make it the same with the mapped ot compatible prefix. But do we
>need to state this? "mapped" are illegal on the wire and "compatible" are
>only for tunnel end point! It could, however, be the "translatable" prefix
>(ala SIIT).

OK put these limitations in.  I am discussing translatable with Erik
now.

>> 6.  In section 5.4 FTP ALG
>> 
>> You need to address the EPRT and EPASV commands being replaced in IPv6
>> FTP with prt and passv as they are different.
>> 
>
>Suresh, can you comment on this?

OK I will await the response.

thanks 
/jim