Subject: AD requests WG review of final revisions to draft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please

From: "William Dixon" <[email-masked]>
Date: Mon, 23 Feb 2004 14:30:53 -0800

The NAT-T requirements draft is in final RFC editor review. Having a fresh
look at this, Bernard and I have proposed a number of changes to the latest
revision. While most are clarifications, the ADs wanted to make sure the WG
got a chance to review these to catch any immediate objections. The authors
believe that none of the proposed changes affect the current solutions. But
we are asking a quick 48hour review period for these changes.

This is the current document to which the change requests below apply:
 ftp://ftp.rfc-editor.org/in-notes/authors/rfc3715.txt 

Note: this link is to a living document. It will go away when the RFC
issues, and will change if the RFC editor makes further changes during the
review process.

On Page 4, change:

"IPsec/GRE" to "IPsec protected GRE"

Change:

"   c) Incompatibility between IKE address identifiers and NAT.  Where IP
      addresses are used as identifiers in Internet Key Exchange
      Protocol (IKE) MM [RFC2409] or QM, modification of the IP source
      or destination addresses by NATs or reverse NATs will result in a
      mismatch between the identifiers and the addresses in the IP
      header.  As described in [RFC2409], IKE implementations are
      required to discard such packets.

      In order to avoid use of IP addresses as IKE MM and QM
      identifiers, userIDs and FQDNs can be used instead.  Where user
      authentication is desired, an ID type of ID_USER_FQDN can be used,
      as described in [RFC2407].  Where machine authentication is
      desired, an ID type of ID_FQDN can be used.  In either case, it is
      necessary to verify that the proposed identity matches that
      enclosed in the certificate.  However, while use of USER_FQDN or
      FQDN identity types is possible within IKE, there are usage
      scenarios (e.g., Security Policy Database (SPD) entries describing
      subnets) that cannot be accommodated this way."

to:

"   c) Incompatibility between IKE address identifiers and NAT.  Where IP
      addresses are used as identifiers in Internet Key Exchange
      Protocol (IKE) Phase 1 [RFC2409] or Phase 2, modification of the IP
source
      or destination addresses by NATs or reverse NATs will result in a
      mismatch between the identifiers and the addresses in the IP
      header.  As described in [RFC2409], IKE implementations are
      required to discard such packets.

      In order to avoid use of IP addresses as IKE Phase 1 and Phase 2
      identifiers, userIDs and FQDNs can be used instead.  Where user
      authentication is desired, an ID type of ID_USER_FQDN can be used,
      as described in [RFC2407].  Where machine authentication is
      desired, an ID type of ID_FQDN can be used.  In either case, 
      it is necessary to verify that the proposed identifier matches that
      enclosed in the certificate if certificates are exchanged in Phase 1. 
      While use of USER_FQDN or FQDN identity types is possible within IKE, 
      there are usage scenarios (e.g., Security Policy Database (SPD)
entries 
      describing subnets) that cannot be accommodated this way.

      Since the source address in the Phase 2 identifier
      is often used to form a full 5-tuple inbound SA selector, the
      destination address, protocol, source port and destination port can
      be used in the selector so as not to weaken inbound SA processing."

Change: 

"   d) Incompatibility between fixed IKE destination ports and NAPT."

To:

"   d) Incompatibility between fixed IKE source ports and NAPT."

Change:

"   e) Incompatibilities between overlapping SPD entries and NAT.  Where
      hosts behind a NAT negotiate overlapping SPD entries with the same
      destination in IKE QM, packets may be sent down the wrong IPsec
      SA.  This occurs because to the sender, the IPsec SAs appear to be
      equivalent, since they exist between the same endpoints and can be
      used to pass the same traffic."

To:

"   e) Incompatibilities between overlapping SPD entries and NAT.  Where
      initiating hosts behind a NAT use their source IP addresses in
      Phase 2 identifiers, they can negotiate overlapping SPD entries with
      the same responder IP address. The responder could then send packets 
      down the wrong IPsec SA.  This occurs because to the responder, the
IPsec 
      SAs appear to be equivalent, since they exist between the same
endpoints 
      and can be used to pass the same traffic."

Change:

"      Note that this is not an incompatibility with IPsec per se, but
      rather with the way it is typically implemented.  With both AH and
      ESP, the receiving host specifies the SPI to use for a given SA.
      At present, the combination of Destination IP, SPI, and Security
      Protocol (AH, ESP) uniquely identifies a Security Association.
      This means that the receiving host can select SPIs, such that it
      has one Security Association (SA) with (SPI=470, Dest
      IP=10.2.3.4), and a different Security Association with (SPI=470,
      Dest IP=10.3.4.5)."

To:

"     Note that this is not an incompatibility with IPsec per se, but
      rather with the way it is typically implemented.  With both AH and
      ESP, the receiving host specifies the SPI to use for a given SA, a 
      choice which is significant only to the receiver. At present, the
      combination of Destination IP, SPI, and Security Protocol (AH, ESP)
      uniquely identifies a Security Association. This means that the
receiving
      host can select SPIs, such that it has one Security Association (SA)
with
      (SPI=470, Dest IP=10.2.3.4), and a different Security Association with
      (SPI=470, Dest IP=10.3.4.5). The receiving NA(P)T will not be able to
      determine which internal host an inbound IPsec packet should be
forwarded
      to."

Change:

      It is also possible for the receiving host to allocate a unique
      SPI to each unicast Security Association.  In this case, the
      Destination IP Address need only be checked to see if it is "any
      valid unicast IP for this host", not checked to see if it is the
      specific Destination IP address used by the sending host.  This
      approach is completely backwards compatible, and only requires the
      particular receiving host to make a change to its SPI allocation
      and IPsec_esp_input() code."

To:

"     It is also possible for the receiving host to allocate a unique
      SPI to each unicast Security Association. In this case, the
      Destination IP Address need only be checked to see if it is "any
      valid unicast IP for this host", not checked to see if it is the
      specific Destination IP address used by the sending host. 
      Using this technique, the NA(P)T can be assured of a low but 
      non-zero chance of forwarding packets to the wrong internal host, 
      even when two or more hosts establish SAs with the same external host.

      This approach is completely backwards compatible, and only requires 
      the particular receiving host to make a change to its SPI allocation 
      and IPsec_esp_input() code.  However, NA(P)T devices cannot
      detect or depend upon this behavior."

Insert after h) and renumber subsequent paragraphs:

"   i) Inbound SA selector verification. Assuming IKE negotiates phase 2 
      selectors, inbound SA processing will drop the decapsulated packet,
since 
      [RFC2401] requires a packet's source address match the SA
      selector value, which NA(P)T processing of an ESP packet would
change."

Change:

"    i) Inability to handle non-UDP/TCP traffic.  Some NAPTs discard non-
      UDP/TCP traffic.  Such NAPTs are unable to pass SCTP, ESP
      (protocol 50), or AH (protocol 51) traffic."

To:

"   j) Inability to handle non-UDP/TCP traffic.  Some NA(P)Ts discard non-
      UDP/TCP traffic or perform address-only translation when only one 
      host is behind the NAT.  Such NAPTs are unable to enable SCTP, ESP
      (protocol 50), or AH (protocol 51) traffic."

In Section 3, change:

"  The goal of an IPsec-NAT compatibility solution is to expand the
   range of usable IPsec functionality beyond that available in the
   NAT-compatible IPsec tunnel mode solution described above."

To:

"  The goal of an IPsec-NAT compatibility solution is to expand the
   range of usable IPsec functionality beyond that available in the
   NAT-compatible IPsec tunnel mode solution described in 
   Section 2.3."

Change:

"     In a gateway-gateway scenario, a privately addressed network (DMZ)
      may be inserted between the corporate network and the Internet.
      In this design, IPsec security gateways connecting portions of the
      corporate network will have private addresses on their external
      interfaces.  A NA(P)T connects the DMZ network to the Internet.

      A NAT-IPsec solution MUST enable secure host-host communication
      via IPsec, as well as host-gateway communications.  A host on a
      private network MUST be able to bring up IPsec-protected TCP
      connections or UDP sessions to another host with one or more
      NA(P)Ts between them.  For example, NA(P)Ts may be deployed within
      branch offices connecting to the corporate network, with an
      additional NA(P)T connecting the corporate network to the
      Internet.  This may require special processing of TCP and UDP
      traffic on the host."

To:

"Gateway-to-Gateway Scenario      

      In a gateway-gateway scenario, a privately addressed network (DMZ)
      may be inserted between the corporate network and the Internet.
      In this design, IPsec security gateways connecting portions of 
      the corporate network may be resident in the DMZ and
      have private addresses on their external (DMZ) interfaces. A NA(P)T
      connects the DMZ network to the Internet. 

End-to-End Scenario

      A NAT-IPsec solution MUST enable secure host-host TCP/IP communication
      via IPsec, as well as host-gateway communications.  A host on a
      private network MUST be able to bring up one or multiple
IPsec-protected
      TCP connections or UDP sessions to another host with one or more
NA(P)Ts
      between them.  For example, NA(P)Ts may be deployed within branch
offices
      connecting to the corporate network, with an additional NA(P)T
connecting
      the corporate network to the Internet. Likewise, NA(P)Ts may be
deployed
      within a corporate network LAN or WAN to connect wireless or remote
      location clients to the corporate network. This may require special
      processing of TCP and UDP traffic on the host."

Change:

"
   At a minimum, an IPsec-NAT compatibility solution MUST support
   traversal of the IPsec modes required for support within [RFC2401].
   For example, an IPsec gateway MUST support ESP tunnel mode NA(P)T
   traversal, and an IPsec host MUST support IPsec transport mode NA(P)T
   traversal.  The purpose of AH is to protect immutable fields within
   the IP header (including addresses), and NA(P)T translates addresses,
   invalidating the AH integrity check.  As a result, NA(P)T and AH are
   fundamentally incompatible and there is no requirement that an
   IPsec-NAT compatibility solution support AH transport or tunnel mode."

To:

"  At a minimum, an IPsec-NAT compatibility solution MUST support
   traversal of the IKE and IPsec modes required for support within
   [RFC2409] and [RFC2401]. For example, an IPsec gateway MUST support ESP
   tunnel mode NA(P)T traversal, and an IPsec host MUST support IPsec
   transport mode NA(P)T traversal.  The purpose of AH is to protect
   immutable fields within the IP header (including addresses), and NA(P)T
   translates addresses, invalidating the AH integrity check.  As a result,
   NA(P)T and AH are fundamentally incompatible and there is no requirement
   that an IPsec-NAT compatibility solution support AH transport or tunnel
   mode."

In Section 4.2, change:

"   RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for
   IPsec traversal, as described in [RSIPsec].  By enabling host-gateway
   communication, RSIP addresses issues of IPsec SPI de-multiplexing, as
   well as SPD overlap.  It is thus suitable for use in enterprises, as
   well as home networking scenarios.  By enabling hosts behind a NAT to
   share the external IP address of the gateway, this approach is
   compatible with protocols including embedded IP addresses."

To:

"  RSIP, described in [RSIP] and [RSIPFrame], includes mechanisms for
   IPsec traversal, as described in [RSIPsec].  By enabling host-NA(P)T
   communication, RSIP addresses issues of IPsec SPI de-multiplexing, as
   well as SPD overlap.  It is thus suitable for use in enterprises, as
   well as home networking scenarios.  By enabling hosts behind a NAT to
   share the external IP address of the NA(P)T (the RSIP gateway), this 
   approach is compatible with protocols including embedded IP addresses."

In Section 5, change:

"  In addition, since ESP with any transform does not protect against
   source address spoofing, some sort of source IP address sanity
   checking needs to be performed.  The importance of the anti-spoofing
   check is not widely understood.  There is normally an anti-spoofing
   check on the Source IP Address as part of IPsec_{esp,ah}_input().
   This ensures that the packet originates from the same address as that
   claimed within the original IKE MM and QM security associations.
   When a receiving host is behind a NAT, this check might not strictly
   be meaningful for unicast sessions, whereas in the Global Internet
   this check is important for tunnel-mode unicast sessions to prevent a
   spoofing attack described in [AuthSource]."

To:

"  In addition, since ESP with any transform does not protect against
   source address spoofing, some sort of source IP address sanity
   checking needs to be performed.  The importance of the anti-spoofing
   check is not widely understood.  There is normally an anti-spoofing
   check on the Source IP Address as part of IPsec_{esp,ah}_input().
   This ensures that the packet originates from the same address as that
   claimed within the original IKE Phase 1 and Phase 2 security
associations.
   When a receiving host is behind a NAT, this check might not strictly
   be meaningful for unicast sessions, whereas in the Global Internet
   this check is important for tunnel-mode unicast sessions to prevent a
   spoofing attack described in [AuthSource], which can occur when
   access controls on the receiver depend upon the source IP address of
   verified ESP packets after decapsulation.  IPsec-NAT compatibility
   schemes should provide anti-spoofing protection if it uses source
   addresses for access controls."

End of changes

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Feb 2004 13:37:12 -0500

William,

I have some concern with the wording in the text.

>       enclosed in the certificate if certificates are exchanged in Phase 1.

the pki4ipsec WG, and 2401bis, are addressing what is required to 
establish that the asserted ID in the IKE payload is authorized 
relative to the authentication data provided. thus the text here 
seems a bit too restrictive when it says "matches that enclosed in 
the certificate ..." I'd suggest something along the lines of "In 
either case, it is necessary to verify that the proposed identifier 
is authenticated as a result of processing an end-entity certificate, 
if certificates are exchanged in Phase 1."

>       be used in the selector so as not to weaken inbound SA processing."

I don't know what this means, precisely. We are clarifying how to use 
named SPD entries in 2401bis, so that there will be no need to talk 
about weakening inbound SA processing.

>       determine which internal host an inbound IPsec packet should be

I'd suggest using the new text on SA demuxing, from the revised AH & 
ESP specs as approved by the WG months ago. it clarifies what is 
required re demuxing for unicast vs. multicast traffic.

>       detect or depend upon this behavior."

again, if one uses the new text to which I alluded above, this is very clear.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 27 Feb 2004 00:14:46 +0200

> the pki4ipsec WG, and 2401bis, are addressing what is required to 

pki4ipsec is just starting now, we do not know what they are going to
be producing. The 2401bis refers also to IKEv2, which have its own NAT
traversal and there are differences in the IDs allowed etc. This
document is now in the RFC editor final step, I do not think we should
be modifying this text based on the future work that is still work in
progress. 

> if certificates are exchanged in Phase 1."

The original text works fine for the current IKEv1 usage, and I do not
think we should be changing the current text at this step. 

> about weakening inbound SA processing.

We do not want to wait for work in progress, i.e. rfc2401bis. This
document refers to rfc2401 which does not have the clarification yet. 

> required re demuxing for unicast vs. multicast traffic.

Again this document refers to rfc2401, rfc2402, rfc2406, this it
cannot use later AH and ESP documents.

If this document would be in normal working group edit phase, then
those changes would propably be ok, but as we are now in the rfc
editor 48 hours notice time, I do not think we should be doing that
kind of changes. 
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 27 Feb 2004 09:50:49 -0500

Tero,

You make a good point, that I overlooked, i.e., that the document in 
question refers to the old set of RFCs. I think that addresses all of 
my comments but the first.

The old set of RFcs does not specify how to verify that a name in the 
IKE ID is to be verified against a cert, so the text here represents 
an extrapolation relative to the old RFCs, and should be changed to 
not impose more specific requirements than what those RFCs stated.

Steve