>>In the IKE_SA_INIT exchange the initiator sends an SA payload
>>listing acceptable proposals. The responder picks one and sends the
>>chosen proposal to the initiator. The identities of the IKE
>>endpoints are not exchanged until the IKE_AUTH exchange. If the
>>identities are not exchanged until the IKE_AUTH exchange, how does
>>the responder know which of the initiator's proposals are acceptable
>>during the IKE_SA_INIT exchange?
>
>By looking at its own security policy.
Where is this policy defined? Is this considered to be a matter
of "local policy" and outside the scope of the RFCs?
>>RFC 4301 discusses the use of the SPD to find acceptable policy for
>>the creation of CHILD_SAs and it discusses the use of the PAD to
>>authenticate IKE endpoints. It does not appear to define a construct
>>to identify what policy is acceptable for the creation of a of an
>>IKE_SA with a specific IKE peer. Does this mean that RFCs 4301 and
>>4306 do support the definition of peer specific policy for IKE_SAs?
>
>No. They support definition of peer-specific policies for IPSEC_SAs.
Strangely enough I don't think the term IPSEC_SA appears in RFC 4301
or 4306. By IPSEC_SA do you mean ESP and AH SAs?
>
>>RFC 4306 states, "All implementations of IKEv2 MUST include a
>>management facility that enables a user or system administrator to
>>specify the suites that are acceptable for use with IKE." This seems
>>to imply that peer specific IKE_SA policy should not be defined and
>>that the responder should pick the most secure proposal that the
>>responder supports. Is that correct?
>
>Yes, approximately.
Could you clarify why you said approximately? To me approximately
means almost correct :>).
Thanks.
_______________________________________________ Ipsec mailing list Ipsec@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ipsec