Steve Baillargeon writes: > - in the section 2.9 on Traffic Selector Negotiation, I think it > will be good to have a few sentences about the relation (or lack of) > between traffic selector and static routing especially when dealing > with AH/ESP tunnel mode. As far as I know many implementers will > automatically add a static route after the traffic selectors are > negotiated.
That will depend on the implementations and I do not think there is any need to add text about that in the IKEv2 document. There is no one universal way of doing that, especially when considering all different types of places where IPsec can be implemented (see section 3.3. of RFC4301). > - how should the initiator behaves if the responder did not return > valid TSi and TSr during Child SA establishment? For instance, the > responder has a "bug" and returns a TSr that is not within the > original requested TSr. Should the initiator sends an INFORMATIONAL > request with error notification TS_UNACCEPTABLE to the responder? The returned traffic selecters are supposed to be subset of the proposed traffic selectors, and if other end violated that rule, then initiator can do whatever it likes. It can consider this like any other fatal implementation error or an attack, i.e. tear down the IKEv2 SA, or it can send error notification to the other end. It cannot accept the wider traffic selector sent by the other end, as that would be violating his policy, and that would break the security of the device. If it is doing proper exit tunnel checks (like it should if it implements IPsec properly), then it might use its own original traffic selectors it proposed to the other end instead of the wider returned one, but that would cause some packets to be dropped silently, as the responder thinks he has wider SA than what the initiator has. I myself would suggest the first option, i.e. consider it as an attack agains the system, and tear down the IKEv2 SA immediately. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
