That was partially because Valery and I didn't fully agree. Which means
it might not belong in this document. Initial Contact is addressed in
the document already in its own section. The question for example is
about CREATE_CHILD_SA. Which comes back to your point below about
making claims of owning an IP range that cannot be verified without
an identity. I'm thinking with my OE hat on, so I am perfectly fine
with restricting things to a single ip-ip connection (with natt support)
and so in such a case the initial exchange is all that is needed and
CREATE_CHILD_SA is never a valid exchange.
Rekeys are not valid? I would expect null authentication method to be
used in cases where they might still want to do rekey, both for Child
SAs and the IKE SA.
Paul's idea was to limit unauthenticated peer to have a single IPsec SA.
I don't think he has rekey in mind, when suggested to prohibit
CREATE_CHILD_SA.
However, since we disageed on that, this prohibition was not inserted
into the document.
Also even in IP-IP connections there might be per protocol+port
connections, i.e. it could be possible to do per tcp-flow Child SAs,
and that is still possible even if you restrict it to single IP-IP
connection.
I agree. This must be a policy issue, not a protocol issue -
whether per-flow SAs are allowed and how many SAs server
is willing to maintain. And the protocol has already
all the means to control it - NO_ADDITIONAL_SAS,
SINGLE_PAIR_REQUIRED, TS_UNACCETPABLE,
ADDITIONAL_TS_POSSIBLE notifications.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
