Subject: [IPsec] IKE6 Negitaion when Peer Address ND not yet started.

From: Syed Ajim Hussain <[email-masked]>
Date: Thu, 18 Feb 2010 14:11:00 +0530

Hi All

   IPv6 Peer1 ------------------ IPv6 Peer 2
     
   I have one question, for IKE IPv6 Solution.   
   Assume in  IPsec6 Policy I have configure Source IPv6 Address and 
   Destination IPv6 Address as Traffic selector, now IPSEC SA is not yet 
   establish.    
   When IKE Triggers, SA Negotiation and that time for peer address, ND not 
   yet done.
    
   In this condition, Initiator starts NS to resolve Peer Address,   
   Other end replies with NA, which is a Uncast packet   Now this unicast 
   packet is comes under IPsec6 policy, So Peer2 can not send it un-
   encrypted, and for encryption SA is not yet ready. 

   Even if Peer2 sends un-encrypted packets , this NA packet may drop in 
   Peer1, as it matches IPsec Policy and still packet is un-encrypted. 

   So, Is there any standard to handle such scenario? Else we need to 
   update standard to Support IPSEC6/IKE6.  

With Regards
Syed Ajim

****************************************************************************

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

****************************************************************************

---

From: Yoav Nir <[email-masked]>
Date: Thu, 18 Feb 2010 11:05:13 +0200

Hi, Syed Ajim.

In future please expand acronyms, because while it's safe to assume that anyone reading this list knows what an SA is, not all of us are proficient in IPv6 terminology.

Having said that, policies usually have exceptions for protocols, that need to run in the clear. IKE is an example of such a protocol. 

Also, when IPsec is between two hosts that are not on the same subnet, you don't have a problem - since your local network is not in the policy, all the neighbor discovery/solicitation/advertisement are in the clear anyway.

You do have a problem when your IPsec peer is on the same subnet. In that case, you need to have an exception in your policy, that makes these protocols non-protected. Alternatively, you can get the peer address from a third party (such as DNS), and use that for IKE, ignoring the IPv6 way of doing discovery. (IKE still needs an exception) Then the whole neighbor protocols will run over IPsec like they should.  This might require some messing around with the IPv6 stack.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Syed Ajim Hussain
Sent: Thursday, February 18, 2010 10:41 AM
To: [email-masked]
Subject: [IPsec] IKE6 Negitaion when Peer Address ND not yet started.

Hi All

    

With Regards
Syed Ajim

---

From: Syed Ajim Hussain <[email-masked]>
Date: Fri, 19 Feb 2010 10:00:27 +0530

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      

 -----Original Message-----
From: Yoav Nir [mailto:[email-masked]] 
Sent: Thursday, February 18, 2010 2:35 PM
To: 'Syed Ajim Hussain'; [email-masked]
Subject: RE: [IPsec] IKE6 Negitaion when Peer Address ND not yet started.

Hi, Syed Ajim.

In future please expand acronyms, because while it's safe to assume that
anyone reading this list knows what an SA is, not all of us are proficient
in IPv6 terminology.

Having said that, policies usually have exceptions for protocols, that need
to run in the clear. IKE is an example of such a protocol. 

Also, when IPsec is between two hosts that are not on the same subnet, you
don't have a problem - since your local network is not in the policy, all
the neighbor discovery/solicitation/advertisement are in the clear anyway.

You do have a problem when your IPsec peer is on the same subnet. In that
case, you need to have an exception in your policy, that makes these
protocols non-protected. Alternatively, you can get the peer address from a
third party (such as DNS), and use that for IKE, ignoring the IPv6 way of
doing discovery. (IKE still needs an exception) Then the whole neighbor
protocols will run over IPsec like they should.  This might require some
messing around with the IPv6 stack.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Syed Ajim Hussain
Sent: Thursday, February 18, 2010 10:41 AM
To: [email-masked]
Subject: [IPsec] IKE6 Negitaion when Peer Address ND not yet started.

Hi All

    

With Regards
Syed Ajim

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Feb 2010 13:21:56 +0200

>       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...
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Sat, 20 Feb 2010 11:21:40 -0500

>       IPsec policy  matches But  No Security Association(SA) presents.

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

---

From: Yoav Nir <[email-masked]>
Date: Sun, 21 Feb 2010 10:17:15 +0200

>   can take care.  It will be problem in Interop also.

Are you volunteering to write such an RFC?

>      IPsec policy  matches But  No Security Association(SA) presents. 

As Tero & Steve replied, you probably need some entries in the SPD just to make IKE/IPsec work. ICMP is one case, IPv6 NS/NA/ND is another, and IKE/IPsec itself is yet another.

<vendor_hat>Some products automatically configure the necessary extra rules for you, but even if they're invisible in the fancy GUI, those extra rules are still there.</vendor_hat>

For now nobody has written a document to describe these, except for the discussion of ICMP in RFC 4301. I'm not sure if such a document is necessary, as any implementor is bound to find out about these requirements very soon.

---

From: Syed Ajim Hussain <[email-masked]>
Date: Mon, 22 Feb 2010 19:22:46 +0530

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-masked]] 
Sent: Saturday, February 20, 2010 9:52 PM
To: Syed Ajim Hussain
Cc: [email-masked]
Subject: Re: [IPsec] IKE6 Negitaion when Peer Address ND not yet started.

Syed,

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 22 Feb 2010 10:48:52 -0500

>     pass ND traffic, it is unto, his own choice.

I see a fundamental misunderstanding here. Vendors don't configure 
SPDs, users do. A vendor may offer a simple UI to enable this sort of 
config, but that's not the same as the vendor making this decision 
for all of the users of its products.

>     ND, can go without IPSEC Encapsulation, even if SDP Matches.

This last statement seems to say that you want IPsec implementations 
to treat these packets specially, and always bypass them, 
irrespective of SPD configurations. I don't we we do this for any 
other type of traffic.

Steve

---

From: Yoav Nir <[email-masked]>
Date: Tue, 23 Feb 2010 10:17:25 +0200

> for all of the users of its products.

<vendor_hat_on>
There are some SPD entries that you need just to make the system work (such as allowing IKE to bypass, or allowing HTTP to the server that's holding the Hash&URL certificates, or HTTP access to wherever the CDP is.

In an environment where IPsec is between hosts on the same subnet, you also need the IPv6 control stuff to be able to bypass.

Users don't think in terms of SPDs. Their policies are written in English, like "encrypt mail and web between our sites, and allow http+https to other places, but block filesharing". The simple UI helps to translate the English policy into SPDs that the products understands. IKE, CRLs and IPv6 control are not part of the policy, and a simple UI will usually add these SPD entries automatically. Some will allow you to turn off these automatic rules (our product has a checkbox that says "Accept control connections") but users are not expected to do that.

So there is a difference between the stated policy that the user configures, and the SPD that finally gets pushed to the IPsec stack.
</vendor_hat_on>

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Feb 2010 10:22:30 -0500

Yoav,

I did not mean to suggest that the SPD UI has to be a low level 
interface that makes it difficult for users to achieve their secruity 
goals.  On the other hand, I would be surprised if any vendor's UI 
really accepted English (or another human communication language). 
So, despite the fact that policies are written in a human 
communication language, those policies need to be entered into a UI 
via a language that is more rigorous. I don't think we're saying 
anything different; we both agreed that a UI can provide simple ways 
for users to enable the needed bypass entries.

RFC 4301, in Figure 1 and Figure 3 shows where IKE lives relative to 
the IPsec boundary, and that implies the need for the sort of SPD 
entries you cited in your message

I do think that Syed was saying something different, i.e., that the 
IPsec architecture document should explicitly say what SPD entries 
must be created to enable bypass of this sort of traffic. That would 
be a bad idea, as it would require revisions to the architecture 
every time some new example of such bypassed traffic arises.

Steve