Hi Steve
According to me IPSEC/IKE should have intelligence by by-pass ND Traffic
when SA is not ready state without end-user intervention, and same
should be accepted by other end.
If some vendor/Product may ask user to add specific rules in SDP to by-
pass ND traffic, it is unto, his own choice.
According to me their should one Guidelines in RFC, Control packet like
ND, can go without IPSEC Encapsulation, even if SDP Matches.
With Regards
Syed Ajim
-----Original Message-----
From: Stephen Kent [mailto:[email protected]]
Sent: Saturday, February 20, 2010 9:52 PM
To: Syed Ajim Hussain
Cc: [email protected]
Subject: Re: [IPsec] IKE6 Negitaion when Peer Address ND not yet started.
At 10:00 AM +0530 2/19/10, Syed Ajim Hussain wrote:
>Hi Yoav Nir & All Group Member
>
> 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.
>
>
>With Regards
>Syed Ajim
>
Syed,
We don't generally provide exceptions for control traffic to cross
the IPsec boundary. Note the extensive discussion in 4301 on ICMP
traffic. What you described above is a policy decision and it needs
to be explicitly stated in the SPD. At most we might remind folks to
configure such SPD entries in an IPv6 environment.
Steve
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
