Syed Ajim Hussain writes: > Thanks for your quick response. I think, instead of user takes special > care by adding extra Rule to allow un-encrypted ND traffic(unicast) , > There should be some RFC guidelines, such that IPSEC/IKE protocol itself > can take care. It will be problem in Interop also. > > Below guidelines can be used. > > 1. if packet is of IPv6 NS/NA types , IPSEC Policy matches , but > Security Association(SA ) not yet established , then send can send > Un- encrypted packets. > > Also Receiver should accept an un-encrypted packet for NS/NA when > IPsec policy matches But No Security Association(SA) presents.
You want to allow neighbor discovery (ND) protocol packet always in clear, even when you have SA. The reason is that for example if the other end reboots, and you still have the IPsec SA, and then other end tries to recreate the IPsec SA, which means it first needs to run IKE, which means it first needs to do neighbor discovery and if your end is ignoring all incoming neighbor solicitation (NS) because they are sent in clear, or if you reply to them using encrypted neighbor advertisenment (NA) messages the other end cannot get your address, thus it cannot recover from the crash. So the best policy is to accept incoming neighbor discovery messages always regardless whether they were in clear or encrypted, and send replies back using same method the request came in (i.e. if it came in as clear text packet, send reply in clear, if it came in encrypted then you might as well reply encrypted (or clear)). Very common initial IPsec IPv6 error is that you do ping first to check that connection works (which does ND in clear), then you start IPsec and try ping again and everything seem to work. Then when you try to keep ping running for longer time, it suddenly stops working... What happend there is that the neighbor cache entry expired, and host tried to do ND again, but now the packets were dropped either because they were sent in clear or encrypted, and other end didn't like them that way... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
