[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AD requests WG review of final revisions to draft-ietf-ipsec-nat-reqts-06.txt <= 48hrs please
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