Tero, I am not comfortable with the following statement:
. . . thus it will send back traffic selectors having IPN1 and IP2
as their IP addresses . . .
I would prefer that the server re-map the TS values back to IP1 and IPN2
when sending its response. This is consistent with the general
expectation that the response's TS payloads are a subset of the request's
payloads. The client does not absolutely need this information (it would
perhaps help for deterministic checksum fixup, however in transport mode
as long as an integrity algorithm is used the checksum provides no
additional value anyway). I think it is also advantageous to contain this
fixup processing to one code path (processing TS payloads in received
requests), and it also simplifies the response message processing (the
client does not need to complicate its checks to verify that the
response's TS payloads are a subset of the request's). This separation of
responsibility is more advantageous to a client implementation that needs
to be as minimal as possible.
Finally, what I propose above is how our own IKEv1 implementation works in
cases where ID payloads are sent for transport mode. :) As a responder we
found it best to bend over backwards to cater to the initiator's view of
the world.
I'm also concerned about the following statement:
After this it does SPD lookup based on those new traffic
selectors. . . .
If entry is found but it does not allow transport mode, then MUST
undo the address substitution and redo the SPD lookup using the
original traffic selectors. . . .
This statement is incoherent to me. From the fact that the initiator
proposed transport mode, it is clear that the initiator identifies TSi
with itself and TSr with the server. The address substitution exactly
translates these addresses into the domain of the responder's SPD. If the
responder's policy indicates that transport mode is not acceptable for
this SPD entry, then I think the only possible outcome is that SA
negotiation should be failed. No other SPD entry could possibly match the
initiator's intentions. However, the MUST quoted above causes the
responder to treat these addresses in an incoherent way:
1) The responder has detected a NAT in front of the initiator, so treating
IP1 as being within the domain of the responder's SPD isn't appropriate;
we need to use IPN1.
2) NATs aside, the responder knows that the initiator identifies IP1 with
the initiator itself (because the initiator proposed transport mode), so
treating IP1 as anything other than the initiator (i.e., IPN1) -- perhaps
as some address behind the initiator for which it is acting as a gateway
-- isn't appropriate, because the initiator could not possibly have had
gateways in mind.
3) The responder has detected a NAT in front of itself, so treating IPN2
as being within the domain of the responder's SPD isn't appropriate; we
need to use IP2.
4) NATs aside, the responder knows that the initiator identifies IPN2 as
the responder (because the initiator proposed transport mode), so treating
IPN2 as anything other than the responder (i.e., IP2) -- as though it were
some address behind the responder for which the responder is acting as a
gateway -- isn't appropriate, because the initiator could not possibly
have had gateways in mind.
I don't think this is an appropriate way for the responder to interpret
TSi and TSr. I propose that the MUST above be changed to "MUST fail the
SA negotiation."
Scott Moonen (smoo...@us.ibm.com)
z/OS Communications Server TCP/IP Development
1-919-254-1388 (T/L: 444-1388)
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen
From:
Tero Kivinen <kivi...@iki.fi>
To:
Yaron Sheffer <yar...@checkpoint.com>
Cc:
"ipsec@ietf.org" <ipsec@ietf.org>
Date:
08/26/2009 12:01 PM
Subject:
[IPsec] #28: Obtaining src/dest IP addresses for UDP-encapsulated
transport mode ESP
Yaron Sheffer writes:
> [2.23, NAT Traversal]
> > o Implementations MUST process received UDP-encapsulated ESP
packets
> > even when no NAT was detected.
> >
> > o The original source and destination IP address required for the
> > transport mode TCP and UDP packet checksum fixup (see
[UDPENCAPS])
> > are obtained from the Traffic Selectors associated with the
> > exchange. In the case of NAT traversal, the Traffic Selectors
> > MUST contain exactly one IP address, which is then used as the
> > original IP address.
>
> Tero:
>
> Getting original source and destination IP address from the traffic
> selectors do not really work currently. Especially when combined with
> the selectors from the packet and when responder is behind nat or
> similar problems.
>
> Paul: Not done. Specify replacement text and discuss on the mailing
list.
>
> People who care about Transport Mode are requested to help resolve this
NAT
> Traversal issue.
I wrote better long description about the problem, and also proposed
solution text at 2009-04-07:
http://www.ietf.org/mail-archive/web/ipsec/current/msg04131.html
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
