headers
pekka huikenen | 1 Jun 2006 10:44
Picon
Favicon

Clarification about Configuration Attributes in IKEv2

Hi all

How are multiple values of an attribute encoded in the configuration 
payload?  For example, DNS is multi-valued, and we may have two DNS server.

Do I encode just one attribute structure with length 8 and the value field 
contains two DNS addresses, or do I encode two separate attribute 
structures, each with length 4 and just one DNS server address?

Thanks.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Permalink | Reply | 1 comment |
headers
Pasi.Eronen | 1 Jun 2006 17:20
Picon

RE: Clarification about Configuration Attributes in IKEv2


Two separate INTERNAL_IP4_DNS attributes, each with length 4. 

Best regards,
Pasi

> -----Original Message-----
> From: ext pekka huikenen [mailto:pekka747 <at> hotmail.com] 
> Sent: 01 June, 2006 11:45
> To: ipsec <at> ietf.org
> Subject: [Ipsec] Clarification about Configuration Attributes in IKEv2
> 
> Hi all
> 
> How are multiple values of an attribute encoded in the configuration 
> payload?  For example, DNS is multi-valued, and we may have 
> two DNS server.
> 
> Do I encode just one attribute structure with length 8 and 
> the value field contains two DNS addresses, or do I encode two 
> separate attribute structures, each with length 4 and just one 
> DNS server address?
> 
> Thanks.
Permalink | Reply | 0 comments |
headers
Martin Willi | 2 Jun 2006 08:50
Favicon

Rekeing of a CHILD_SA with AH+ESP in IKEv2

Dear subscribers,

It is not absolutely clear to me how to do the rekeying of a CHILD_SA, if its
traffic is protected by AH AND ESP. The use of both protocols may be
questionable, but it's possible in IKEv2 and therefore I want to support it.

I've done the following assumptions:
  - a CHILD_SA consists of a AH and/or ESP security assocation, this means
    it's just ONE CHILD_SA, even if there are two/four (kernel level)
    security associations involved. Correct?
  - If I set up AH and ESP in one CHILD_SA, those SAs may be identified by
    different SPIs. Correct? I haven't found a clear statement about this, but
    the inclusion of an SPI in every proposal substructure leads to this
    assumption.

Now what means "rekeing a CHILD_SA"? What's to do if one of those 
SAs (ESP or AH) expire? For me, two approaches are possible:
1. Rekey the full CHILD_SA (ESP and AH SA) at once. If so:
  - Which SPI should be included in the REKEY_SA notify? Or include two of
    them?
2. Rekey every SA seperately. If so:
  - What sould be included in the SA-payload? Only proposals for the specific 
    protocol?

I hope someone can give me clarity about this.

Thanks in advance
Martin Willi
Permalink | Reply | 6 comments |
headers
Alejandro Perez Mendez | 2 Jun 2006 09:04
Picon
Favicon

Re: Rekeing of a CHILD_SA with AH+ESP in IKEv2

Hi!

Some time ago I did the same question. You can read the discussion here

http://www1.ietf.org/mail-archive/web/ipsec/current/msg01781.html

At the end, we decide to eliminate all the SA bundles support from
OpenIKEv2, due it is not clear how to support them and it was not a very
important feature for us.

Best regards!
--
Alejandro Perez Mendez
OpenIKEv2 developer
http://openikev2.sf.net

El vie, 02-06-2006 a las 08:50 +0200, Martin Willi escribió:
> Dear subscribers,
> 
> It is not absolutely clear to me how to do the rekeying of a CHILD_SA, if its
> traffic is protected by AH AND ESP. The use of both protocols may be
> questionable, but it's possible in IKEv2 and therefore I want to support it.
> 
> I've done the following assumptions:
>   - a CHILD_SA consists of a AH and/or ESP security assocation, this means
>     it's just ONE CHILD_SA, even if there are two/four (kernel level)
>     security associations involved. Correct?
>   - If I set up AH and ESP in one CHILD_SA, those SAs may be identified by
>     different SPIs. Correct? I haven't found a clear statement about this, but
>     the inclusion of an SPI in every proposal substructure leads to this
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pasi.Eronen | 2 Jun 2006 11:30
Picon

RE: Rekeing of a CHILD_SA with AH+ESP in IKEv2

Hi,

You probably want to check out Section 7.13 (Combining ESP and
AH) in draft-eronen-ipsec-ikev2-clarifications. 

Best regards,
Pasi

> -----Original Message-----
> From: ext Martin Willi [mailto:martin <at> strongswan.org] 
> Sent: 02 June, 2006 09:51
> To: Ipsec <at> ietf.org
> Subject: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2
> 
> Dear subscribers,
> 
> It is not absolutely clear to me how to do the rekeying of a 
> CHILD_SA, if its traffic is protected by AH AND ESP. The use of both 
> protocols may be questionable, but it's possible in IKEv2 and 
> therefore I want to support it.
> 
> I've done the following assumptions:
>   - a CHILD_SA consists of a AH and/or ESP security assocation, 
>     this means it's just ONE CHILD_SA, even if there are two/four 
>     (kernel level) security associations involved. Correct?
>   - If I set up AH and ESP in one CHILD_SA, those SAs may be 
>     identified by different SPIs. Correct? I haven't found a 
>     clear statement about this, but the inclusion of an SPI in 
>     every proposal substructure leads to this assumption.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tero Kivinen | 2 Jun 2006 13:23
Picon
Picon
Favicon

Rekeing of a CHILD_SA with AH+ESP in IKEv2

Martin Willi writes:
> Dear subscribers,
> 
> It is not absolutely clear to me how to do the rekeying of a CHILD_SA, if its
> traffic is protected by AH AND ESP. The use of both protocols may be
> questionable, but it's possible in IKEv2 and therefore I want to support it.

There is not really AH AND ESP in RFC4301 architecture. There is
TCP/UDP inside ESP and ESP inside AH. I.e. AH+ESP is generated by
first creating SA encrypting traffic with ESP and then creating
separate SA that will authenticate the ESP packets by adding AH around
them. Those two SAs are created as two separate IKE CREATE CHILD SA
exchanges. 

> I've done the following assumptions:
>   - a CHILD_SA consists of a AH and/or ESP security assocation, this means
>     it's just ONE CHILD_SA, even if there are two/four (kernel level)
>     security associations involved. Correct?

Wrong. AH and ESP are separate SAs each having different traffic
selectors. The ESP have traffic selectors of the real traffic to be
protected, and the AH has traffic selectors matching the ESP traffic. 

>   - If I set up AH and ESP in one CHILD_SA, those SAs may be identified by
>     different SPIs. Correct? I haven't found a clear statement about this, but
>     the inclusion of an SPI in every proposal substructure leads to this
>     assumption.

You create AH and ESP as two CREATE_CHILD_SAs, each having one SPI in
SA payload, and only one protocol in each proposal. Each of those
(Continue reading)

Permalink | Reply | 3 comments |
headers
Markku Savela | 2 Jun 2006 13:53

Re: Rekeing of a CHILD_SA with AH+ESP in IKEv2

> From: Tero Kivinen <kivinen <at> iki.fi>

> Wrong. AH and ESP are separate SAs each having different traffic
> selectors. The ESP have traffic selectors of the real traffic to be
> protected, and the AH has traffic selectors matching the ESP traffic. 

...

> See the section 5.1 of the RFC4301, and notice that the SPD cache
> returns you exactly one SA, which is used to process the pcaket with
> either AH or ESP (but not both), and then the packets goes to the
> Forwarding check, that will resend the packet to beginning again, now
> with new selectors and then the SPD cache will return another SA and
> you do the second process step for the packet.

I'm somewhat troubled by above description. I heartily support the
idea that AH and ESP are negotiated independently. This was my prime
objection for IKEv1 from the start.

But, your selector thing is a bit problematic. In IPv6, AH and ESP are
extension headers. Seems odd that after extension header processing,
the packet would go into "forwarding check" etc. This not the way our
stack works.

I believe the selectors should always be for "transport level". If you
protect TCP or UDP traffic with AH + ESP, I say the selectors for AH
and ESP should still be the TCP/UDP and ports.

This way the basic IPsec implementations (not including IKE) would be
compatible between RFC-2401 and 4301 implementations.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pasi.Eronen | 2 Jun 2006 15:39
Picon

RE: Rekeing of a CHILD_SA with AH+ESP in IKEv2

Markku Savela wrote:
> I'm somewhat troubled by above description. I heartily support the
> idea that AH and ESP are negotiated independently. This was my prime
> objection for IKEv1 from the start.
> 
> But, your selector thing is a bit problematic. In IPv6, AH and ESP are
> extension headers. Seems odd that after extension header processing,
> the packet would go into "forwarding check" etc. This not the way our
> stack works.

Going back to forwarding check is required to handle nested IPsec
SAs between different endpoints.

E.g. suppose that I have an IPsec tunnel (ESP or AH) between my laptop 
at  home and the company VPN gateway. Inside that tunnel, there can be
another SA (ESP or AH) for protecting traffic between the laptop and 
some server X located inside the company intranet. So when a packet
arrives down from UDP/TCP, it's first processed using the latter SA
(laptop-server X), then goes to forwarding check, and then processed
using the former SA (laptop-gateway).

In RFC4301, AH+ESP between the same endpoints is basically handled
same way as two nested SAs with different endpoints (and there's
no difference between IPv4 and IPv6 here).

Best regards,
Pasi
Permalink | Reply | 1 comment |
headers
Markku Savela | 2 Jun 2006 16:36

Re: Rekeing of a CHILD_SA with AH+ESP in IKEv2


> Going back to forwarding check is required to handle nested IPsec
> SAs between different endpoints.

That's ok, in this context the inner IP header provides the right
trigger. That is not the problem.
Permalink | Reply | 0 comments |
headers
Poorna Pushkala B | 9 Jun 2006 12:33
Picon

Is it mandatory to have the incoming and outgoing SA protocol and encryption/auth algorithms same?

Hi,
I am relatively new to ipsec. 
Is it mandatory to have the incoming and outgoing Security Association protocol (AH/ESP) and encryption/auth algorithms same?
I went through RFC 2401, though it defines a Security Association, it is not clear if for a given VPN tunnel, the incoming and outgoing SAs should use the same protocol ( AH/ESP).

Can you help me?

Thanks & Regards
Kala. B

_______________________________________________
Ipsec mailing list
Ipsec <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
Permalink | Reply | 4 comments |

Gmane