[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPsec support for NAT-PT in IPv6




-----Original Message-----
From: 최인석 [mailto:ischl@cns.ssu.ac.kr] 
Sent: Friday, October 29, 2004 11:30 PM
To: 'Francis.Dupont@enst-bretagne.fr'
Subject: RE: IPsec support for NAT-PT in IPv6 



-----Original Message-----
From: Francis.Dupont@enst-bretagne.fr [mailto:Francis.Dupont@enst-
bretagne.fr] 
Sent: Friday, October 29, 2004 9:44 PM
To: 최인석
Cc: v6ops@ops.ietf.org
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

Francis.Dupont@enst-bretagne.fr

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