Michael Richardson <mcr+i...@sandelman.ca> wrote: >> I think such an IPsec SA really conflates two different IPsec SA's. For >> example, a service on a port where the IPsec SA is both for incoming and >> outgoing connections are really two security contexts that can be split >> into two IPsec SAs one for client (any to port X) and one for server >> (port Y to any)
>> So in a way, a NOTIFY might make sense. But then we do run the risk of >> an IPsec SA being installed with the notify ignored using a default >> security context instead of the security context required. Having it >> as part of the TSi/TSr payloads makes that a lot more clear. >> Thoughts? > It has to be a traffic selector. It has to be a traffic selector so that it can be selected (so do labeled IPsec SA), or not selected (do not do it). Any other mechanism (notification) can not be unambiguously rejected by a responder. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec