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

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



William,

I have some concern with the wording in the text.

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

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


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

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.

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

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.

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

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