Jari Arkko wrote:
> > If the IPsec SAs were updated in the previous step:
> > If NAT Traversal is not enabled, and the responder
> > supports NAT Traversal (as indicated by NAT detection
> > payloads in the IKE_SA_INIT exchange), and the
> > initiator either suspects or knows that a NAT is
> > likely to be present, enables NAT Traversal.
> >
> > I did not understand this step at all. If the IPsec SAs were
> > updated, then the RR check won't be done. What is that got
> > to do with NAT traversal ?
>
> Good question. I don't they have much to do with each other.
> It seems that the actions in this step should be done in any
> case.
>
> Also, "enables NAT traversal" is a bit vague. Presumably we
> are sending payloads and making specific actions on the results
> of seeing payloads come back.
The reasoning is that updating the addresses in IPsec SAs and
enabling/disabling NAT Traversal go together: if you don't do RR
check, you do both immediately; but if you wait for the RR check to
finish, you also don't toggle NAT-T before you've updated the
addresses in the SA.
"Enabling NAT traversal" here means starting UDP encapsulating
outgoing ESP packets and sending NAT-Keepalive packets (i.e.,
it doesn't involve sending any IKEv2 payloads, other than those
already explicitly specified in that section).
How about adding "(i.e., enables UDP encapsulation of outgoing ESP
packets and sending of NAT-Keepalive packets)" there?
> > If there are outstanding IKEv2 requests (requests for
> > which the initiator has not yet received a reply),
> > continues retransmitting them using the addresses in
> > the IKE_SA (the new addresses).
> >
> > This does not have a corresponding section in what the
> > responder. Though, trivial would make sense to include
> > them.
>
> Yes.
The responder processes the requests as usual: if the request
was CREATE_CHILD_SA, creates the new SA or something, etc.
Note that the responder's part start with this text:
When processing an INFORMATIONAL request containing the
UPDATE_SA_ADDRESSES notification, the responder:
so I'm not sure what should be added here?
> >- Section 4.7
> >
> > If the initiator is behind NAT, and if he suspects
> > that the peer is *dead*, he can send a DPD message
> > with UPDATE_SA_ADDRESSES to recover faster. This was
> > discussed in the mailing list sometime back. But i
> > don't see this suggestion. Why do we have to know that
> > the NAT mapping has changed explicitly ? If the path
> > still does not work with UPDATE_SA_ADDRESSES, then
> > probably the path has failed.
>
> Tero, Pasi, can you say something about this?
Knowing that the NAT mapping has changed might be useful, since
it allows you to adjust the keepalive interval. But the initiator
could also send the UPDATE_SA_ADDRESSES immediately.
How about adding "The initiator MAY also omit the separate
exchange to detect the change in NAT mappings, and instead send
UPDATE_SA_ADDRESSES immediately when doing dead peer detection."
to 3rd paragraph of Section 4.7?
> >- Section 4.9
> > Can we show the DPD exchange here with possible
> > payloads ?
>
> We have an example in Section 3.2. Would that be sufficient,
> or do you want more?
There is no "DPD exchange" in IKEv2; any INFORMATIONAL exchange
confirms the peer is alive (and thus it can include whatever
payloads any other INFORMATIONAL exchange includes).
Best regards,
Pasi
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.