Subject: RE: IPsec support for NAT-PT in IPv6

From: 최인석 <[email-masked]>
Date: Tue, 2 Nov 2004 12:15:20 +0900

-----Original Message-----
From: 최인석 [mailto:[email-masked]] 
Sent: Friday, October 29, 2004 11:30 PM
To: [email-masked]'
Subject: RE: IPsec support for NAT-PT in IPv6 

-----Original Message-----
From: [email-masked] [mailto:Francis.Dupont@enst-
bretagne.fr] 
Sent: Friday, October 29, 2004 9:44 PM
To: 최인석
Cc: [email-masked]
Subject: Re: IPsec support for NAT-PT in IPv6 

 In your previous mail you wrote:

   Comments welcome.
   
=> in section 2.1:
   The IP addresses are usually used as the ID values in this procedure.

 this is not true: draft-ietf-pki4ipsec-ikecert-profile-03.txt:
   ... Of these types, FQDN and USER_FQDN are
   RECOMMENDED over IP addresses (see discussion in Section 3.1.1).

   and in section 3.1.1 there is the rationale:

   Implementations SHOULD NOT populate ID payload with IP addresses due
   to interoperability issues such as problems with NAT traversal, and
   problems with IP verification behavior.

 So the solution is simple: avoid (put a MUST NOT) ID payload with
 IP addresses as it is already done for the NAT traversal.

=> section 2.2 describes a NAT problem, not a NAT-PT problem.
I don't understand why section 3 doesn't try to extend the NAT traversal
mechanism...

=> section 4 doesn't make sense : IKE already works well through a NAT.

=> idem for section 5. If the only issue is the transport checksum
the current NAT traversal has NAT-OA payloads to fix it.

So my recommendation is to refer to RFC 3715 (IPsec-Network Address
Translation (NAT) Compatibility Requirements) and its companion solution
I-D draft-ietf-ipsec-nat-t-ike-08.txt

Regards

[email-masked]

----------------------------------------------------------------------------
Thanks for your comment
Basically NAT-PT is likely NAT, but you give consideration to translation
from IPv6 to IPv4 or from IPv4 to IPv6.
  
In 2.1 ==> Only if IKE procedure uses FQDN and USER_FQDN, you are correct.
But I think FQDN and USER_FQDM is not usually use in real application.

In 2.2 ==> It is NAT-PT problem which ICV calculate problem.
             NAT-PT node calculate with IPv6 header and Payload, however
IPv4
             node verify IPv4 header and Payload.

In 4 ==> IKE doesn't work well through a NAT, because it has firewall issue.
           Therefore Solution was offered IPsec-Tunnel mode and RSIP in NAT.
In 5 ==> IPsec AH mode problem is ICV calculation using IP header but not
transport checksum.

---

From: "Inseok Choi" <[email-masked]>
Date: Tue, 2 Nov 2004 15:16:44 +0900

in 2.1 ==> My proposed mechanism was assume IKE using preshared key Phase.
If we can't IKE using use certificate, we should use IKE using other way.

in IPsec using UDP encapsulation ==> NAT-PT can't apply to it. If we use
IPsec using UDP encapsulation in NAT-PT, NAT-PT server may send IPv4-in-
IPv6 packet. However IPv4 node don't understand IPv6 packet.

Therefore, NAT traversal method can be applied to NAT-PT mechanism.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Francis Dupont
Sent: Friday, October 29, 2004 9:44 PM
To: 최인석
Cc: [email-masked]
Subject: Re: IPsec support for NAT-PT in IPv6 

   Comments welcome.
   
=> in section 2.1:

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 04 Nov 2004 14:42:18 +0100

* IKE ==> In environment which it use dynamic address(DHCP, NAT, ...), as
   possible as we use IKE using CERT. but IKE can't surely use CERT in
   condition (ex> no CERT, authentication of IP address).
   In real IKE procedure, I think we need to see things from various
   methodology.
   
=> you are simply trying to make NAT-PT an exceptional case: I disagree,
NAT traversal, "road warriors", etc, are already known and handled cases.

   * IPsec using UDP encapsulation in NAT-PT
   ==> If we use IPsec using UDP encapsulation, see below
   1. NAT ==> |New IPv4 header|UDP|Original IPv4 header|IKE or AH payload|

=> there is no such "Original IPv4 header" (IKE doesn't tunnel and
AH is usable in tunnel mode only in theory).

   2. NAT-PT ==> |New IPv4 header|UDP|Original IPv6 header|IKE of AH payload|
   
=> same.
The only problem is with ESP transport:

New IPv4 header|optional UDP|ESP {ESP header|Original IPv6 packet|ESP trailer}
where of course the Original IPv6 packet, likely encripted, can't be
understood by the IPv4 only peer. But NAT-PT can't do something,
this is just a service (ESP tunnel) which doesn't make any sense
in this context.

   NAT can use UDP encapsulation method because no change Original IPv4 header.
   and opposite peer can understand original IPv4 packet.
   But NAT-PT can't use same method because opposite peer can't understand
   original IPv6 packet.
   
=> please read NAT traversal and UDP encapsulation drafts...
      
Regards