Subject: [IPsec] One question for IKE/IPsec

From: Hui Deng <[email-masked]>
Date: Wed, 13 May 2009 20:56:49 +0800

Dear IPsec forks,

May I consult one question here:

Whether we could still do IKEv2 negotiation (Authenticaiton),
but not use IPsec tunnel?

Thanks for your clarificaiton.
Best regards,

-Hui

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2009 08:04:50 -0700

>but not use IPsec tunnel?

You never need to use a tunnel, regardless of how it was brought up. The tunnel can just sit there, feeling lonely and abandoned, waiting for traffic.

--Paul Hoffman, Director
--VPN Consortium

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 May 2009 18:53:35 +0300

Paul Hoffman wrote:
> >Whether we could still do IKEv2 negotiation 
> (Authenticaiton), but not 
> >use IPsec tunnel?
> 
> You never need to use a tunnel, regardless of how it was 
> brought up. The tunnel can just sit there, feeling lonely and 
> abandoned, waiting for traffic.

Yes, but you can't rely on the peer not having a policy that says "all tunnels that are idle for 30 seconds get deleted"

Email secured by Check Point

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 May 2009 09:06:04 -0700

>Yes, but you can't rely on the peer not having a policy that says "all tunnels that are idle for 30 seconds get deleted"

Of course, but that's not what Hui asked. In his scenario, he should assume that the tunnel will get nuked by one side or the other either due to disuse or an active management choice.

--Paul Hoffman, Director
--VPN Consortium

---

From: Hui Deng <[email-masked]>
Date: Thu, 14 May 2009 22:07:01 +0800

Thanks Paul and Yoav, excuse me for late reply.

Tunnel waitting for traffic means that all traffic have to go through
this tunnel anyhow.
the scenario I described is that after IKE procedure, but all the
traffic will not go through this Ipsec tunnle since they are point to
point connection.

Many thanks for your advice.

-Hui

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 14 May 2009 08:51:17 -0700

>Tunnel waitting for traffic means that all traffic have to go through

Correct.

>traffic will not go through this Ipsec tunnle since they are point to

I am deeply confused. Why would point-to-point traffic not go through a tunnel that has the appropriate traffic selectors? Where else would the traffic go?

--Paul Hoffman, Director
--VPN Consortium

---

From: Hui Deng <[email-masked]>
Date: Fri, 15 May 2009 20:10:00 +0800

You are right, after IKE phase 1, IPsec SA will be setup,
traffic selector will be used

Here our requirement is, we still create the IKE SA, but not create IPsec SA.
the reason for such kind of strange usage is that IKE is already mandated there.
the left is whether it is necessary to use IPsec since the connections
are already physically secured.

Excuse for such strange scenario.

-Hui

---

From: "Grewal, Ken" <[email-masked]>
Date: Fri, 15 May 2009 08:18:34 -0600

All, 
In an attempt to get consensus and closure on some of the open tickets for traffic visibility, I am providing the following summary. I look forward to your feedback...

#84: Wesp scope and applicability to encrypted data. Agreed that we will use Next Header value of zero to denote packet payload is encrypted. Should be closed?

#85: units for header / trailer len. Updated in rev 02 - Gabriel is owner and needs to update / close ticket.

#88: UDP encap diagram is wrong - fixed in rev 02. Additionally, Yaron's comment on updating reference to 4306 from 3947 - will address in next rev.

#89:  Version handling - added some text, but need to add additional text on how this is treated by intermediate devices, as well as recipients - see discussion on ML.

#90: Shorter WESP negotiation using notifications - added this to rev02 - all agree that this is the right approach?

#91: Next Header field should not be optional for ESP-NULL. Added text to rev 02.

#92: Clarify how to treat the flags. This is similar to #89 and will clarify further in next rev. 

#93: Next header to provide value of tunneled packet. Some comments on ML indicate that Next Header value in WESP should be same as Next Header value in ESP trailer. This provides consistency and aids easy validation by recipient - need to add text to indicate consistency between tunnel / transport mode.

#104: Handling malformed fields in WESP header. This is similar to Next header corruption and will add text to ensure recipient validates these as per suggestions on ML.

Side issue: Between rev-01 and rev-02, moved WESP flags to beginning of WESP header. Rationale was to place flags first, so any packet format changes in the future can be accommodated by checking the flags and then inferring the subsequent formatting. Offline comment prefers the flags to be at end of WESP header, as per rev-01 of draft. Any preference from others? Raise a separate ticket for this?

Thanks,
Ken

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 15 May 2009 08:09:23 -0700

>are already physically secured.

You can run IKE and then immediately delete the IPsec / Child SA but leave the IKE SA up. This should probably pass your odd requirements.

>Excuse for such strange scenario.

Many of us have seen worse...

--Paul Hoffman, Director
--VPN Consortium

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 15 May 2009 18:41:21 +0300

Hi Ken,

Tero mentioned that two more fields must be zero when the payload is
encrypted. Is this covered by any of the open issues?

Thanks,
	Yaron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Grewal, Ken
> Sent: Friday, May 15, 2009 17:19
> To: [email-masked]
> Subject: [IPsec] IPsecME traffic visibility open item summary
> 
> All,
> In an attempt to get consensus and closure on some of the open tickets for
> traffic visibility, I am providing the following summary. I look forward
> to your feedback...
> 
> #84: Wesp scope and applicability to encrypted data. Agreed that we will
> use Next Header value of zero to denote packet payload is encrypted.
> Should be closed?
> 
> #88: UDP encap diagram is wrong - fixed in rev 02. Additionally, Yaron's
> comment on updating reference to 4306 from 3947 - will address in next
> rev.
> 
> #89:  Version handling - added some text, but need to add additional text
> on how this is treated by intermediate devices, as well as recipients -
> see discussion on ML.
> 
> #90: Shorter WESP negotiation using notifications - added this to rev02 -
> all agree that this is the right approach?
> 
> #93: Next header to provide value of tunneled packet. Some comments on ML
> indicate that Next Header value in WESP should be same as Next Header
> value in ESP trailer. This provides consistency and aids easy validation
> by recipient - need to add text to indicate consistency between tunnel /
> transport mode.
> 
> #104: Handling malformed fields in WESP header. This is similar to Next
> header corruption and will add text to ensure recipient validates these as
> per suggestions on ML.
> 
> Side issue: Between rev-01 and rev-02, moved WESP flags to beginning of
> WESP header. Rationale was to place flags first, so any packet format
> changes in the future can be accommodated by checking the flags and then
> inferring the subsequent formatting. Offline comment prefers the flags to
> be at end of WESP header, as per rev-01 of draft. Any preference from
> others? Raise a separate ticket for this?
> 
> 
> Thanks,
> Ken
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> Scanned by Check Point Total Security Gateway.

---

From: "Grewal, Ken" <[email-masked]>
Date: Fri, 15 May 2009 11:23:57 -0600

Thanks Yaron - I will capture this as part of the text on packet handling
and field validation.

Thanks, 
- Ken

>From: Yaron Sheffer [mailto:[email-masked]]
>Sent: Friday, May 15, 2009 8:41 AM
>To: Grewal, Ken; [email-masked]
>Subject: RE: IPsecME traffic visibility open item summary
>
>Hi Ken,
>