Subject: [Ipsec] SPD & IKE v2

From: Tero Kivinen <[email-masked]>
Date: Wed, 2 Mar 2005 13:22:37 +0200

Stephen Kent writes:
> This brings me to the issue Tero raised in this discussion. Tero, I 
> think you suggested that there is a fundamental mismatch between what 
> the SPD allows to be expressed and what IKE v2 can negotiate. 
> Specifically, I think you indicated that the mismatch arises because 
> IKE semantics  call for a "mix and match" approach to viewing TSi/TSr 
> payloads.

Yes. The IKEv2 does not tie TSi and TSr together in anyway. It says
you process TSi and TSr separately, i.e. there is no text there saying
they would be tied together in any ways.

> I looked at section 2.9 in IKE v2 and I don't see where it 
> suggests this.

Do you see any text there which could indicate that the TS payload
items are somehow paired? It does say that both TSi and TSr SHOULD
have very specific entries as their first entries. 

> For example, the text describes how to pass triggering 
> packet header data as the FIRST selector set data in TSi and TSr 
> payloads, implying that the order of elements in these payloads is 
> important, and that one is expected to view them as pairs, matching 
> the corresponding S/D address and port fields.

I cannot see how it implies that there is any order for the rest of
the items, when you say that the first item must be from packet if you
ant to include it. We needed some way to find the specific from packet
TS item, and instead of adding a flag or using separate TS type for
that we decided to put it as a first item in the list. We already
found out in the interop event that this can cause confusion, as some
people didn't understand that the first item can be very specific. And
in some cases is it impossible to find out wheather there is one
specific entry or not.

> So, I have to admit 
> that I am confused by your comment. If I send a series of pairs of 
> TSi/TSr payloads, I would interpret this to represent pairs of S/D 
> data, with a common protocol, so that each matched pair represents 
> one selector set from an SPD entry, if the entry has more than one 
> selector set in it.

One of the ideas is that the initiator can send TS:

TSi = 0.0.0.0-255.255.255.255
TSr = 0.0.0.0-255.255.255.255

and the responder can narrow it down to:

TSi = 10.0.11.22-10.0.11.22
TSr = 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255

etc.

> Can you cite the parts of IKEv2 that suggest the "mix and match" 
> approach that you indicated?

It does use mix and match in all other cases with similar lists. Can
you find out where it says you should pairwise tie TS together? It
does not say anywhere that there should be even equal number of items
in the TSi and TSr. 

> Such semantics make no sense in the access control context that the
> SPD represents.

It does make perfect sense for me. I.e. the TSi lists the IP-address
ranges which can be found from the initiators end of the network, and
TSr contains the list of address ranges which can be found from the
responders end.

I.e. if you have VPN setup where the site A has networks 10.0.22.0/24
and 10.0.44.0/24, and the site B has
10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then the TSi will contain
the networks from site A has, and TSr of the request will have
0.0.0.0-255.255.255.255, and the responde will narrow that any ip down
so that TSi will still have 10.0.22.0/24 and 10.0.44.0/24 and the TSr
will now have the networks site B has.

This would not be possible if the TS items would be tied together, as
it would cause lots of TS items to be created. We tried to avoid
combinatory explosion in the IKEv2.

> Also, I'd like to think that IKE should be trying to negotiate what
> the SPD specifies, to minimize the likelihood that SAs are
> established that later will not carry the intended traffic.

I think you earlier said it other way around, i.e. the SPD was
specified to be able to negotiate what the IKEv2 can negotiate. I
think I did comment this earlier when you were writing the ASN1
version of the SPD, but as I am now behind bad network connections I
cannot search the archives. 
-- 
[email-masked]

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Mar 2005 07:19:01 -0800

>in some cases is it impossible to find out wheather there is one

Tero is right. In fact, the document quite clearly says that the 
first transform does *not* need to be for an actual packet, if you 
want to start a tunnel without traffic. Further, I see nothing that 
suggests that "one is expected to view them as pairs".

--Paul Hoffman, Director
--VPN Consortium

---

From: Surya Batchu <[email-masked]>
Date: Wed, 2 Mar 2005 10:14:39 -0800 (PST)

IMO, it is good to have an indication in TS payload indicating that this payload has packet header selectors. 
 
For example, assume that IPsec 'protect' policy on one side has 11.1.5.0/24-->10.1.6.0/24 and
the policy on the peer has 10.1.0.0/16 -> 11.1.5.0/24. Since, one side has smaller range of selectors, the SAs that get established will always be between 11.1.5.0/24 and 10.1.6.0/24.
Upon packet reception from say 10.1.7.0/24 network to 11.1.5.0/24 network, the peer starts childSA transaction as there is no matching outbound SA. In this case, the initiator sends both packet header TS payloads and security policy selectors. If the responder considers packet selectors and other selectors in the same fashion, then , it again creates SA with the same selectors as previous SA ie 11.1.5.0/24 and 10.1.6.0/24.  This might happen over and over again and it might flood the SA session table.
 
Implementations can be smart to avoid SA flood or implementation can be smart to know that there is a TS payload pair with packet selectors. But, having protocol support to identify  packet selectors from other selectors  really helps in simplification of implementations. If responder knows that, this SA is being negotiated for a given packet selector without any ambiguity, then the responder can choose to return error notification to the Initiator, for above transaction.
 
Surya

Paul Hoffman <[email-masked]> wrote:

--Paul Hoffman, Director
--VPN Consortium

		
---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
 Yahoo! Netrospective: 100 Moments of the Web

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Mar 2005 11:41:50 -0800

At 10:14 AM -0800 3/2/05, Surya Batchu wrote:
>IMO, it is good to have an indication in TS payload indicating that 
>this payload has packet header selectors.

I think it is *way* too late for that for the current spec. There is 
no space currently in the headers for that.

--Paul Hoffman, Director
--VPN Consortium

---

From: Surya Batchu <[email-masked]>
Date: Wed, 2 Mar 2005 12:13:29 -0800 (PST)

I understand that it is too late for a change in the headers. 
 
What is the best practice to tackle the kind of problems, which I described in my earlier email , with existing TS payload information? In the first place, is that a valid problem? 
 
Surya

--Paul Hoffman, Director
--VPN Consortium

---

From: Surya Batchu <[email-masked]>
Date: Wed, 2 Mar 2005 12:35:10 -0800 (PST)

I went through the Appendix C of  http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-05.txt. I think that SPD syntax mentioned in here can be negotiated through IKEv2 selector payloads. I am pasting here relevant portions of ASN1 syntax here:

 SelectorLists ::= SET OF SelectorList

      SelectorList ::= SEQUENCE {
          localAddr   AddrList,
          remoteAddr  AddrList,
          protocol    ProtocolChoice }
 
  -- List of IP addresses
      AddrList ::= SEQUENCE {
          v4List      IPv4List OPTIONAL,
          v6List      [0] IPv6List OPTIONAL }

      -- IPv4 address representations
      IPv4List ::= SEQUENCE OF IPv4Range

      IPv4Range ::= SEQUENCE {    -- close, but not quite right ...
          ipv4Start   OCTET STRING (SIZE (4)),
          ipv4End     OCTET STRING (SIZE (4)) }

      -- IPv6 address representations
      IPv6List ::= SEQUENCE OF IPv6Range

      IPv6Range ::= SEQUENCE {    -- close, but not quite right ...
          ipv6Start   OCTET STRING (SIZE (16)),
          ipv6End     OCTET STRING (SIZE (16)) }

Based on above, 'localAddr' and 'remoteAddr' are two differnet fields in SelectorList. 
Each one of them can have multiple IP address ranges.
 
To me, it seems both rfc2401bis and IKEv2 TS are conforming to each other.
Am I missing some thing?
 
Surya

Tero Kivinen <[email-masked]> wrote:

etc.

---

From: Saroop Mathur <[email-masked]>
Date: Wed, 2 Mar 2005 12:53:24 -0800 (PST)

> >this payload has packet header selectors.

I believe such an indication will be really useful. It can be
generalized to indicate "the responder must include this TS in the
subset selected by the responder". This also allows an initiator to
have some say in what the negotiated TS will be. e.g. if a initiator
supports only a single SA for the entire subnet and does not want the
responder to narrow the TS, it currently cannot indicate this. Most
SOHO VPN boxes only support a few SAs and will be at the mercy of the
responder to not narrow down the policy.

> no space currently in the headers for that.

I agree it is way too late for such a change, however, if a change is
desired, space can be created in the TS header. Currently, the
"Selector Length" field is 16 bits. It could be reduced to 8 bits and 1
bit out of the remaining 8 bits be used for this indication. This
leaves 7 bits for future expansion.

-Saroop

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 02 Mar 2005 16:12:58 -0500

On Wed, 2005-03-02 at 15:53, Saroop Mathur wrote:
> responder to narrow the TS, it currently cannot indicate this. 

section 2.9 already says:

   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include as the first traffic selector in each of TSi
   and TSr a very specific traffic selector including the addresses in
   the packet triggering the request.

I think the feature you're looking for is already (mostly) there;
clarifications may be in order but I don't think we need to change the 
encoding.

> Most SOHO VPN boxes only support a few SAs and will be at the mercy of the

In my experence, the folks operating the security gateway generally
specify requirements on the SOHO VPN boxes they allow to connect.  

Either the SG operators will avoid policies which force narrowing in this
case, or they will pick SOHO VPN boxes without this limit.  

While I am well aware that many embedded systems operate in the face
of severe memory limits, I also keep seeing hobbyist reports of things like:
	http://www.batbox.org/wrt54g-linux.html
which suggest that hard limits which would constrain a SOHO device 
to only support a handful of SA's are largely a thing of the past.

						- Bill

---

From: Stephen Kent <[email-masked]>
Date: Wed, 2 Mar 2005 16:13:36 -0500

>suggests that "one is expected to view them as pairs".

Paul,

I did not say that the first pair of selectors were always from the 
triggering packet. what I said was that when the header data from a 
triggering packet is sent, it is sent as the first pair of entries in 
the TSi/r payloads.

What that says to me is that IKE is conveying the initiator and 
responder address and port data from a single packet as a linked pair 
of TSi/r values. The semantics in this case seem clear, i.e., there 
is an specific relationship between the TSi/r values, based on the 
source of these values.

Steve

---

From: Saroop Mathur <[email-masked]>
Date: Wed, 2 Mar 2005 13:25:17 -0800 (PST)

> I think the feature you're looking for is already (mostly) there;

There is no way currently for the initiator to tell the responder not
to narrow a range. The packet header selectors are only specify that
the narrowed range must include the packet selectors.

> Either the SG operators will avoid policies which force narrowing in
> this case, or they will pick SOHO VPN boxes without this limit.

Of course all TS negotiation problems can be avoided by matched polices
at both ends. But IKEv2 is designed for handling mismatched policies.

-Saroop

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 02 Mar 2005 16:40:37 -0500

> the narrowed range must include the packet selectors.
...
> at both ends. But IKEv2 is designed for handling mismatched policies.

yes.  and it does that through narrowing.  TANSTAAFL.

If you disable narrowing, you lose the ability to find the policy 
intersection; if your client box can't cope with multiple SA's and wants
to stop narrowing you'll need to change the SG's policy anyway to get
bits to move.

							- Bill

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Mar 2005 13:43:51 -0800

>clarifications may be in order but I don't think we need to change the

Disagree. There is no way to know whether the first proposal is for a 
first packet or for a future-desired flow. Further, the way the 
document is worded, you are supposed to make the first selector for 
the first packet *even if you don't want to actually have that flow*. 
For example, you might send an ICMP ping just to get the tunnel up, 
even if you don't intend to have ICMP in the enventual tunnel. In 
fact, that is quite common.

--Paul Hoffman, Director
--VPN Consortium

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 2 Mar 2005 14:06:34 -0800

At 5:02 PM -0500 3/2/05, Bill Sommerfeld wrote:
>On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote:
>
>>  Further, the way the
>why would you ask for an SA you didn't intend to use?

Because the IKEv2 document says you SHOULD.

>>  even if you don't intend to have ICMP in the enventual tunnel.
>
>if the peer doesn't want to let ICMP in, it should reject all proposals.

That leads to lack of interop, yes?

>if, instead, the peer narrows to exclude non-ICMP, the initiator should
>just ask for another child SA with the real selectors when real traffic
>comes along.

Right.

--Paul Hoffman, Director
--VPN Consortium

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 02 Mar 2005 17:02:57 -0500

- Bill

---

From: Kevin Li <[email-masked]>
Date: Wed, 02 Mar 2005 14:09:11 -0800

Bill Sommerfeld wrote:

...

- Bill

There is a small problem for always narrowing TS in case the initiator
want all (exact match) or nothing.

In this case, the ipsec SA has already been created on responder side
for narrowing TS. But the initiator doesn't like it (policy "accept all
or noththing"), then the initiator needs to explicitly tell the
responder to delete the SA. This is ok, but undesirable.

It would be nice if the initiator can convey such information to the
responder.

Thanks.

Kevin

---

From: Kevin Li <[email-masked]>
Date: Wed, 02 Mar 2005 14:19:03 -0800

> Because the IKEv2 document says you SHOULD.
I don't think IKEv2 spec should dictate how IKE negotiation is 
triggered. Agree with Paul that the first traffic selector doesn't have 
to be the traffic triggering the IKE negotiation.

Thanks.

Kevin

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 02 Mar 2005 17:27:55 -0500

> Because the IKEv2 document says you SHOULD.

can you be more specific?  I don't see that at all.

> That leads to lack of interop, yes?

correctly in this case (no intersection between the initiator's proposal
and the peer's policy).

when a real (non-speculative) packet comes along, a real tunnel would
be set up.

							- Bill

---

From: "Subha" <[email-masked]>
Date: Wed, 2 Mar 2005 16:26:43 -0800

Hi All,

I also think that IKEv2 and 2401-bis are conforming to each other. I would
appreciate if someone could indicate why they are not.

Thanks,
Subha
  ----- Original Message ----- 
  From: Surya Batchu 
  To: Tero Kivinen ; Stephen Kent 
  Cc: [email-masked] 
  Sent: Wednesday, March 02, 2005 12:35 PM
  Subject: Re: [Ipsec] SPD & IKE v2

    -- List of IP addresses
        AddrList ::= SEQUENCE {

        IPv6Range ! ::= SEQUENCE {    -- close, but not quite right ...
            ipv6Start   OCTET STRING (SIZE (16)),
            ipv6End     OCTET STRING (SIZE (16)) }

  Surya

    Do you see any text there which could indicate that the TS payload
    items are somehow paired? It does say that both TSi and TSr SHOULD
    have very specific entries as t! heir first entries. 

    > So, I ! have to admit 

    etc.

    > Also, I'd like to ! think that IKE should be trying to negotiate what

------------------------------------------------------------------------------
  Celebrate Yahoo!'s 10th Birthday! 
  Yahoo! Netrospective: 100 Moments of the Web 

------------------------------------------------------------------------------

---

From: "Srinivasa Rao Addepalli" <[email-masked]>
Date: Wed, 2 Mar 2005 16:42:34 -0800

Multiple duplicate SA problems can happen for multiple reasons. You indicate
one such scenario. It is a better implementation technique to use some sort
of throttling on number of SAs (with same selectors) that can be present at
any time.  

By the way, having an indication in TS that it has packet selectors is good.
But as others indicated, it may be too late for that kind of change. 

Srini

IMO, it is good to have an indication in TS payload indicating that this
payload has packet header selectors. 

For example, assume that IPsec 'protect' policy on one side has
11.1.5.0/24-->10.1.6.0/24 and

the policy on the peer has 10.1.0.0/16 -> 11.1.5.0/24. Since, one side has
smaller range of selectors, the SAs that get established will always be
between 11.1.5.0/24 and 10.1.6.0/24.

Upon packet reception from say 10.1.7.0/24 network to 11.1.5.0/24 network,
the peer starts childSA transaction as there is no matching outbound SA. In
this case, the initiator sends both packet header TS payloads and security
policy selectors. If the responder considers packet selectors and other
selectors in the same fashion, then , it again creates SA with the same
selectors as previous SA ie 11.1.5.0/24 and 10.1.6.0/24.  This might happen
over and over again and it might flood the SA session table.

Implementations can be smart to avoid SA flood or implementation can be
smart to know that there is a TS payload pair with packet selectors. But,
having protocol support to identify  packet selectors from other selectors
really helps in simplification of implementations. If responder knows that,
this SA is being negotiated for a given packet selector without any
ambiguity, then the responder can choose to return error notification to the
Initiator, for above transaction.

Surya

At 1:22 PM +0200 3/2/05, Tero Kivinen wrote:
>found out in the interop event that this can cause confus! ion, as some

--Paul Hoffman, Director
--VPN Consortium

  _____  

Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 <http://birthday.yahoo.com/netrospective/>
Moments of the Web

---

From: Yoav Nir <[email-masked]>
Date: Thu, 3 Mar 2005 10:59:01 +0200

> why would you ask for an SA you didn't intend to use?

You might want to do this for a remote client.  The client has a 
"Connect" button.  The software has no way on knowing what the user is 
going to do after clicking "Connect".  In IKEv1 it would do only Phase 
1.  In IKEv2 you can't do only phase 1, so you need to make some child 
SA in there.  Making an SA for simple ICMP between the client and the 
gateway (just one address and protocol in each TS) is one way.  You 
could also suggest the entire Internet (0.0.0.0-255.255.255.255) and 
have the gateway narrow that to some range or bunch of ranges which may 
or may not be useful later.  In the case of a generic client I think 
the latter approach is more appropriate, especially if it doesn't have 
a matched policy with the gateway.  Doing the whole thing with the 
"Connect" button and 4-8 packets only to fail because the gateway 
blocks ICMP is a bad idea.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Mar 2005 08:29:28 -0500

At 1:22 PM +0200 3/2/05, Tero Kivinen wrote:

>	<SNIP>

We agree that if an initiator wants to send header data from a 
triggering packet, then the data is sent as the first pair of entries 
in the TSi/r payloads. In this case, it seems clear that the 
semantics here is that these entries are paired, i.e., the responder 
should interpret the pair of entries as representing the S/D address 
and port data from the triggering packet.  Do you agree?

But, there is no flag that indicates whether the first entry is from 
a triggering packet, not, as others have noted. Thus if the responder 
always treats the first pair of TSi/r addresses & ports as matched, 
which is the sensible interpretation when this first pair represents 
triggering packet data, then it will do so even when the first pair 
does NOT represent such data.  So, why change the interpretation for 
later pairs of S/D addresses & ports?

>TSr = 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255

I don't disagree that you can save space in IKE messages under some 
circumstances by being able to associate one payload for one 
direction with multiple ones for the other direction. However, if we 
do not have a way to represent a one-to-one correspondence between 
TSi and TSr values, then we cannot convey the semantics of the SPD, 
and that is not OK.

>does not say anywhere that there should be even equal number of items

The example I gave, for the first set of values in TSi/r implies a 
1-to-1 (paired) matching in this case. Also, the purpose of the IKE 
negotiation is to represent an SPD entry to a peer. SPD entries, like 
analogous ACL entries, are paired. Because we create pairs of SAs 
that represent traffic bidirectional traffic flows that are common in 
the IP context, one expresses ACLs in terms of these bidirectional 
flows.

>TSr contains the list of address ranges which can be found from the

The example you provide is a reasonable one, but it represents a very 
simple case where the mix and match approach expresses the underlying 
access control semantics. However, in the more general case, I may 
want to express the notion that Host A in my net can be accesses by 
Host B in your net and Host C in my net can be accessed by Host D in 
your net, AND I want the traffic for both of these flows to be 
carried via one SA. The SPD allows one to express this notion, and 
IKE needs to be able to convey it. That is how firewalls express 
access control policy (modulo the use of SAs) and the IPsec SPD is a 
standardized representation of such an access control policy.

>combinatory explosion in the IKEv2.

I agree that we should minimize combinatorial explosion, but the SPD 
is a local representation of access control policy and one cannot 
express the sort of constraints that may be necessary if the TS 
proposals are treated as your suggest. IKE could have a different 
structure for the TS proposals, one that would satisfy both goals. It 
could allow for compact representation of the cases where one wants 
to list only selector range for one direction and bind multiple 
ranges to the other direction. But, we do not have that and I sense a 
lot of resistance to making a change of this sort at this point in 
time.

>cannot search the archives.

I'm afraid you have this backwards :-)

I have said that we tried to work to align the SPD and IKE, so that 
we could negotiate in IKE what the SPD expresses.  We had mismatches 
in 2401bis vs. IKE v1 in that we could express things in the SPD that 
IKE could not negotiate. While it is true that I have said that we 
wanted to make sure that IKE v2 and 2401bis are aligned, there is a 
priority here, i.e., 2401bis specifies access control policies and 
IKE v2 exists to negotiate SAs consistent with these policies, not 
the other way around.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 3 Mar 2005 08:59:26 -0500

>appreciate if someone could indicate why they are not.

I think the problem is that the SPD specifies pairs of TSi/r values, 
per protocol, to be bound to an individual SA (assuming no use of the 
PFP feature). If one interprets IKE proposals the way I suggest, then 
one can negotiate SAs consistent with the SPD. However, as Tero 
noted, in some cases this will result in significant IKE message size 
growth, that may cause fragmentation problems. The reason for the 
growth is that if we need to convey paired TSi/r address and port 
data, then one might have to replicate a TSi or TSr value to maintain 
the pairing. Tero gave examples of this.

So we have a few options of how to address this problem:

	1. change IKE to allow explicit binding of TSi/r values, so 
that one can unambiguously represent both 1-to-1 and 1-to-many 
relationships.  this is the best answer, in principle, but folks are 
understandably reluctant to make a change to IKE syntax at this time.

	2. require 1-to-1 matching of IKE payloads, to allow 
representation of SPD semantics. this does not change IKE syntax, but 
does change IKE processing rules, and can result in growth in the 
size of IKE messages in certain contexts, with attendant 
fragmentation concerns.

	3. change the SPD syntax and semantics to accommodate the 
limitations of the IKE syntax. this will cause multiple SAs to be 
created in some contexts, where the current semantics would allow 
multiple traffic flows to be carried via a single SA.

if we do not go with #1, then we have a tradeoff: we can create 
bigger proposals (#2) or create more SAs (#3) each undesirable 
outcome arising under certain conditions.

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Mar 2005 19:46:02 +0200

Saroop Mathur writes:
> I believe such an indication will be really useful.

Yes it would be usefull, but not possible at this time.

> It can be generalized to indicate "the responder must include this
> TS in the subset selected by the responder".

That is already there in the document. It says:

----------------------------------------------------------------------
   If the responder's policy does not allow it to accept the entire set
   of traffic selectors in the initiator's request, but does allow him
   to accept the first selector of TSi and TSr, then the responder MUST
   narrow the traffic selectors to a subset that includes the
   initiator's first choices. In this example, the responder might
   respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and
   IP protocols.
----------------------------------------------------------------------

I.e. regardless wheather the first traffic selector item is from
packet or not, it MUST be included in to the returned TS set. This is
MUST, not SHOULD, so there is no other way to do that. This text does
not say what to do if the initiators first traffic selector item is
not completely allowed, but subset of it would be allowed. I would
think that in that case the negotiation should fail with
TS_UNACCEPTABLE. 

So if the initiator is creating the SA based on the policy not based
on packet, and does not send TS items matching the packet, then the
responder must still include the first TS item inside its narrowed
selectors, i.e. it cannot narrow the first selector down at all.

I.e. if initiator send TS 10.0.0.0-10.0.255.255, and responder has
only 10.0.0.0-10.0.200.255 configured, then responder will return
TS_UNACCEPTABLE. If responder has 10.0.0.0-10.255.255.255 configured,
then it will return 10.0.0.0-10.0.255.255 back (i.e. no narrowing).
I.e. in that case the policy must either match exactly or the
responder must have wider policy. In most cases both ends will have
same policy as this is statically configured vpn system.

If the first packet is from packet it usually means that it is
actually included to some other traffic selector too. I.e. initiator
sends 10.0.0.1-10.0.0.1 proto y port x, and 10.0.0.0-10.0.0.255 proto
any port any. Now if the responder have policy of 10.0.0.0-10.0.0.128
proto from packet port any, then he can return one TS of
10.0.0.0-10.0.0.128 proto x port any. That returned TS is subset of
the union of all input TS items (actually subset of second TS item,
but as the first TS item is subset of second their union is actually
exactly same as second TS), and also the first TS item from the
initiator is also included in this TS item.

> This also allows an initiator to have some say in what the
> negotiated TS will be. e.g. if a initiator supports only a single SA
> for the entire subnet and does not want the responder to narrow the
> TS, it currently cannot indicate this. Most SOHO VPN boxes only
> support a few SAs and will be at the mercy of the responder to not
> narrow down the policy.

If the responder is configured to require separate SA for each port
then there is nothing the initiator can do in the exchange. Their
policies are simply not compatible with each other. 

> leaves 7 bits for future expansion.

All lengths inside the IKE payloads are 16 bits, and we might want to
have TS type later having more than 256 bytes. It would be much easier
to add a new TS type of TS_IPV4_PACKET and TS_IPV6 PACKET having
format of:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !   TS Type     !IP Protocol ID |       Selector Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Port               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      !                                                               !
      ~                         Address                               ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and use that to specify the information about the exact packet. But
as said earlier, it is too late for this kind of changes.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Mar 2005 20:02:53 +0200

Yoav Nir writes:
> going to do after clicking "Connect".

If you press connect button the initiator is not requesting the SA due
to the data packet, thus you do not send the packet specific data in
the TS.

The paragrap describing how to send the TS starts:
----------------------------------------------------------------------
   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include ...
----------------------------------------------------------------------

I.e. the SHOULD only matters if "the initiator has requested the SA
due to a data packet".

I think that SHOULD should be MUST instead of SHOULD, I do not really
understand now why it is SHOULD as it does not cover this kind of
"connect button" or "autostart" cases, thus there is no point of ever
leaving that TS out.

Anyways as it is SHOULD now, it will stay SHOULD, it is too late to
change that.

Note, that the section which says that responder MUST return TS which
includes the the first TS from the initiator is NOT specific to this
case. That MUST be followed always. I.e. responder do not have option
to return TS which does not match the first TS completely.

This actually solves those SOHO VPN users problem. They configure the
TS to be "autostart", i.e. initiated from the beginning without data
packet, and the first TS included is something that the responder must
accept completely, or fail the negotiation. Of course it will still
cause all the negotiations to fail if the responder is configured to
only allow subset of the first TS.

> In IKEv1 it would do only Phase 1. In IKEv2 you can't do only phase
> 1, so you need to make some child SA in there.

Why are you making the IKE SA if you do not intend to use it?

> Making an SA for simple ICMP between the client and the gateway
> (just one address and protocol in each TS) is one way. You could
> also suggest the entire Internet (0.0.0.0-255.255.255.255) and have
> the gateway narrow that to some range or bunch of ranges which may
> the latter approach is more appropriate, especially if it doesn't
> have a matched policy with the gateway. Doing the whole thing with
> the "Connect" button and 4-8 packets only to fail because the
> gateway blocks ICMP is a bad idea.

If you are doing the client, you should always include the entire
internet as destination, and also for source unless you have IP
address already configured.

I.e. if you do not have IP address yet, you send TSi and TSr both to
include full 0.0.0.0-255.255.255.255 and
::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF, and allow the responder
gateway to assign you both IPv4 and IPv6 addresses (using
Configuration payload), and also narrow your TSi to only include IP
addresses it assigned to you, and narrow TSr to include the
IP-addresses which can be reaced through it.

If you have IP-address already (statically configured), then you set
your TSi to be exactly that, and still use full internet as TSr. 
-- 
[email-masked]

---

From: Kevin Li <[email-masked]>
Date: Thu, 03 Mar 2005 10:20:04 -0800

Why the initiator must/should have the first packet selector specifying
first packet?

If initiator wants the first packet to be accepted by the responder, it
could well be included in a TS range which he wants remote end to
accept. There is no reason to extract this particular TS out from that
range. If the remote end doesn't want to accept the traffic type in
first packet according to its local policy, it will reject it any way
either through TS_UNACCEPTIBLE or exclude that from the narrowing down
TS.

Thanks.

Kevin

Tero Kivinen wrote:

Yoav Nir writes:

Further, the way the

---

From: Saroop Mathur <[email-masked]>
Date: Thu, 3 Mar 2005 10:39:09 -0800 (PST)

> think that in that case the negotiation should fail with

However, the very next paragraph states:
-----------------------
   If the initiator creates the CHILD_SA pair not in response to an
   arriving packet, but rather - say - upon startup, then there may be
   no specific addresses the initiator prefers for the initial tunnel
   over any other.  In that case, the first values in TSi and TSr MAY
be
   ranges rather than specific values, and the responder chooses a
   subset of the initiator's TSi and TSr that are acceptable. 
------------------------

Hence the responder can narrow the first values in the TSi and TSr.

-Saroop

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Mar 2005 21:21:03 +0200

> triggering packet, then the data is sent as the first pair of entries 

Not "first pair" of entries. It says that in each of TSi and TSr the
first traffic selector SHOULD be from packet. The document does not
talk about them as pairs.

The IKEv2 document does not refer items in TSi or TSr as pairs
anywhere.

> and port data from the triggering packet.  Do you agree?

No. As there can be only one from packet item taken from the packet to
be used in both TSi and TSr. We simply insert those specific items as
a first items of the list of TSi and TSr. I do not think that makes
items to be paired.

The interpretation of pairs for all TSi and TSr items is entirely
yours, and I cannot really see any support for that from the document.

If we would consider them as pairs, why do we have two payloads then?
It would be much better to define one TS payload having format:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !   TS Type     !IP Protocol ID*|       Selector Length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      initiator start port     |    initiator end port         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      responder start port     |    responder end port         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                    initiator starting address                 ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                    initiator ending address                   ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                    responder startting address                ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                                                               !
      ~                    responder ending address                   ~
      !                                                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

That would be much easier and would make it explicit that we are using
them as pairs.

We do not do that, and the reason is that we did want to say that all
items inside the TSi are combined together (i.e. we take the union of
all items), and any of them can be used as a initiator end selectors.

And separately from that we take all items from the TSr and take the
union of them and any of them can be used as a responder end
selectors.

> later pairs of S/D addresses & ports?

The inclusion of the trigger packet data was added quite late, and we
didn't want to change the format of the TS payloads at that point.
That information was not there from the beginning, it was added around
May 2002.

Note also that the interpretation of the traffic selectors do not
change depending if there is packet specific TS item or not. The first
TS item in both TSi and TSr MUST be included in the narrowed reply of
responder (always!). You could say that the first item in both lists
is the most important TS item from the initiators point of view, and
he does not even want to have an SA up if responder cannot include
that first TS item.

> TSi and TSr values, then we cannot convey the semantics of the SPD, 

Yes, I agree that SPD currently does not match to the one what IKEv2
does. In my email <[email-masked]>
(http://www.vpnc.org/ietf-ipsec/mail-archive/msg00092.html) I tried to
explain that:

----------------------------------------------------------------------
Also in the IKEv2 there is no construct of AddrList at all, we have
two lists (source and destination) of Traffic Selectors (==
SelectorSet), each having on start and end addresses (IPRange), and
port range.

Because in the IKEv2 we do have separate source and destination lists,
it will remove the combinatory explosion, thus the same example can be
expressed as (using the format described in the end of this email):
...
Using same syntax the actual TrafficSelector which can be expressed in
the IKEv2 is:

SPD ::= SEQUENCE of SPDEntry			-- List of SPD Entries

SPDEntry ::= SEQUENCE {				-- Each entry consist of
	source		TrafficSelectorList,	-- source and 
	destination	TrafficSelectorList }	-- destination selectorlists

TrafficSelectorList ::= SET OF TrafficSelector	-- Each selectorList
						-- is list of selectors

TrafficSelector ::= SEQUENCE {			-- either source or
						-- destination selector
	Addr		IPRange,
	protocol	INTEGER,	-- 8 bits
	next CHOICE {
		ports	SEQUENCE {
				portStart	INTEGER, -- 16 bits
				portEnd }	INTEGER, -- 16 bits
		ICMP [0] SEQUENCE {
			typeStart	INTEGER,	-- 8 bits
			codeStart	INTEGER,	-- 8 bits
			typeEnd		INTEGER,	-- 8 bits
			codeEnd		INTEGER } } }	-- 8 bits

IPRange	::=	CHOICE {
			v4range		SEQUENCE {
						start	INTEGER, -- 32 bits
						end	INTEGER } -- 32 bits
			v6range [0]	SEQUENCE {
						start	INTEGER, -- 128 bits
						end	INTEGER } } -- 128 bits
----------------------------------------------------------------------

You replied in your email <p06020402bc359b1b8fac@[128.33.244.157]>
(http://www.vpnc.org/ietf-ipsec/mail-archive/msg00098.html) saying:
----------------------------------------------------------------------
>Also in the IKEv2 there is no construct of AddrList at all, we have
>two lists (source and destination) of Traffic Selectors (==
>SelectorSet), each having on start and end addresses (IPRange), and
>port range.
>
>Because in the IKEv2 we do have separate source and destination lists,
>it will remove the combinatory explosion, thus the same example can be
>expressed as (using the format described in the end of this email):

yes, but the SPD is also used to represent bypass and discard access 
controls.  So, maybe we need to define two classes of entries, one 
for IPsec SA creation and one for bypass/discard, where the IKE 
selector payload conventions do not apply. Also, the PFP flag is not 
in this syntax, yet, and it does need to be in the syntax for the 
former class of SPD entries, even though it is not sent in the IKE 
payload.

... removed other discussion
... my version of ASN1 of SPD

I like the more compact syntax, but we need to resolve the 
disagreement about the protocol field representation in IKE, and 
maybe adopt the conventions re ICMP type/code values. We also need 
text to accommodate the mobility header support. Plus, I need to add 
in the PFP flag, and create a separate entry type for bypass/discard.
----------------------------------------------------------------------

So that is the reason we have the more compact syntax which do not
match the thing what IKEv2 does. 

> 1-to-1 (paired) matching in this case.

It does not say word "pair" anywhere there. It says that both TSi and
TSr lists will have the first entry from packet, it does not say
anywhere that they are otherwise paired.

> Also, the purpose of the IKE negotiation is to represent an SPD
> entry to a peer. SPD entries, like analogous ACL entries, are
> paired. Because we create pairs of SAs that represent traffic
> bidirectional traffic flows that are common in the IP context, one
> expresses ACLs in terms of these bidirectional flows.

I assumed that rfc2401bis and IKEv2 were supposed to be aligned here.
IKEv2 has been negotiating them mix and match all the time. I do not
have any idea why we would like to have combinatory explosion of the
TS payloads in case where you have 10 subnets in initiator end and 100
in the responders end.

> carried via one SA.

And that thing cannot be negotiated with IKEv2 with single SA. If you
want that you need to request multiple SAs. 

> The SPD allows one to express this notion, and IKE needs to be able
> to convey it.

We cannot start doing big modifications to IKEv2 now. We already have
implementations out there which are doing things as they are defined
in the draft. 

You should have commented this year ago, when we discussed this on the
list, and I pointed out that IKEv2 do use completely separate lists
for TSi and TSr, and they are not paired together (as you can see from
my ASN1, and from my comment about the combinatory explosion).

> That is how firewalls express access control policy (modulo the use
> of SAs) and the IPsec SPD is a standardized representation of such
> an access control policy.

The "modulo the use of SA" is very important difference here. SPD and
IKEv2 are aligned already now with module the number of SAs used. We
can always convert paired SPD list to multiple IKEv2 exchanges and
create multiple SAs from them. This will satisfy the SPD firewall
access control policy requirements.

The other way is not true, if you do not allow mix and match you might
end up in combinatory explosion which makes the UDP packet too big to
be able passed through the net. We tried hard to make the UDP packets
small, and remove all combinatory explosions we found, and this was
one of them.

> proposals are treated as your suggest.

I do not understand why not? The only difference there is weather you
can negotiate it with one exchange in the IKEv2 and create one SA or
not. You can take the paired output and create separate SAs for each
pairs, if it really is important not to allow mix and match. I think
in most cases the mix and match is much more common case than the
paired case (i.e initiator have few IP-addresses, and responder have
few subnets). This is especially true in the IPv6 environment or mixed
IPv4 and IPv6 environment.

> IKE could have a different structure for the TS proposals, one that
> would satisfy both goals. It could allow for compact representation
> of the cases where one wants to list only selector range for one
> direction and bind multiple ranges to the other direction. But, we
> do not have that and I sense a lot of resistance to making a change
> of this sort at this point in time.

We can still change rfc2401bis. We cannot really change IKEv2. IKEv2
does not say anything about TSs to be paired, and the intention was
them to be mix and match. The ASN1 SPD is just example, so it is not
normative. Is there any text in the rfc2401bis which says that you
must be able to create non mix-and-match policies using exactly one
SA (instead of creating separate SA for each of them). 

> I'm afraid you have this backwards :-)

IKEv2 was finished first and approved, so I assumed that was ok for
everybody, and we still want SPD and IKEv2 to align, so that leaves us
the choices to modify SPD :-)

> IKE v2 exists to negotiate SAs consistent with these policies, not 

IKEv2 can negotiate that kind of non mix and match policies without
any problem, but it will need to create separate SA for each of them.

Do you really see that as a problem? It do cause more packets to be
send through the network, and more SAs to be created, but the things
will work and implementations will be interoperable.

On the other hand if we allow combinatory explosion of TS items then
IKEv2 packets might be disappearing because they are simply too big.
That will not work, and it will cause problems in the real world uses.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Mar 2005 21:25:58 +0200

> So we have a few options of how to address this problem:

Good summary.

> size of IKE messages in certain contexts, with attendant 

This will break already existing implementations. There are people who
have started implementing the IKEv2 as it is in the rfc-editor
queue... 

> outcome arising under certain conditions.

We cannot go with #1.

The tradeoff between #2 and #3 is:

#2 => sometimes the negotiations with certain policy will fail
#3 => everything works, but we create more SAs

I think getting working protocol is more important than creating
minimalistic number of SAs. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Mar 2005 21:59:25 +0200

> However, the very next paragraph states:

Hmm... true, didn't read it that far now, and didn't remember there
was that text there. I would say that this MAY actually conflicts with
the MUST in the previous paragraph, or is the implicit "if the
initiator has requested the SA due to a data packet" added to the
beginning of that paragraph too? If so we end up problems as responder
cannot know wheather the SA was requested due to a data packet.
-- 
[email-masked]

---

From: [email-masked]
Date: Thu, 3 Mar 2005 15:40:26 -0800 (PST)

Hi all,

I have some issues regarding the message ID in IKE header and window size
in IKEv2.

My understanding from the IKEv2 draft regarding message IDs is:

1. Requests has to be sent by incrementing message ID
2. Receiver must accept all the messages of window size, then only it
should move its current accepted message ID.

Suppose the window size is 2 and the current message ID is 2.
and the sender starts sending two CREATE_CHILD_SA exchange requests of
message IDs 3 and 4.

May be  due to some problem, receiver did not receive the message of
message ID 3.

Should the receiver accept the messages of message IDs 5 and 6 which fall
outside the window??

My feeling is that it SHOULD accept the messages because the message IDs
are authenticated.
Even if the message id received is very big and falls outside the window,
it SHOULD be
accepted.

Thanks,
Jyothi

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 4 Mar 2005 17:01:32 +0200

> May be  due to some problem, receiver did not receive the message of

Which means that initiator will never get ACK from responder to
message ID 3, and after some time it will tear down the IKE SA and
start over. 

> Should the receiver accept the messages of message IDs 5 and 6 which fall

It MUST ignore those messages, as they cannot be sent by proper
initiator. Initiator cannot send those messages, as he cannot have
received the ACK for the message ID 3, thus he must be waiting for
that before he can start sending message ID 5.

> My feeling is that it SHOULD accept the messages because the message IDs

If the messages are authenticated properly, it means that the
initiator is not following the spec or there is attacker on the wire
who has broken the keying material. In any case the initiator and
responder has ended up in the inconsistent state, which means that
responder should probably tear down the IKE SA and start over. 

I assume this question is because the IPsec window and IKE windows are
completely different.

In IKE window when you send message ID 2, you mark that you have sent
message ID 2 out in the window. When you get reply back from the other
end, you mark that you have received reply back for the ID 2, and if
that is first item in the window you slide the window forward. If you
want to send a message when you do not have space in the window, you
fail the exchange internally before even allocating message ID for it.

So lets take example of window code with responders window size of 2.

IWindow = Input window, having n slots of packets, and start ID
telling which is the message ID of the first packet in the window.

RWindow = Response window, having n slots of packets, and start ID 
telling which is the message ID of the first packet in the window.

OWindow = Output window, having n slots. Each slot can be empty, done
or have a packet. Start ID telling which is the message ID of the
first packet in the window.

Initiator				 Responder
---------				 ---------

OWindow = (empty, empty), start = 220,	 IWindow = (218, 219), start = 218

Allocating message ID, getting ID 220
Puts message ID 220 to window:
OWindow = (220, empty), start = 220

220 ->		       <packet is lost>

Notices that haven't received reply
to ID 220, retransmits 220 from the
OWindow

220 ->

					Receives 220, slides 
					the window, and stores the
					packet. 

					IWindow = (219, 220), start = 218

					Generates reply to 220

					Stores reply to RWindow, after
					sliding it forward

					RWindow = (219R, 220R), start = 219

			<reply is lost>	<- 220R

Notices that haven't received reply
to ID 220, retransmits 220 from the
OWindow

220 ->

					Receives 220, notices it is
					retransmission from the
					initiator, checks that packet
					matches the copy in IWindow,
					retranmits 220R from the
					RWindow

					<- 220R

Gets 220R, marks it in the OWindow
that it is done, and slides window
forward.

OWindow = (empty, empty), start = 221

			<- 220R Packet was duplicated in the nwtwork
			for some reason

Receives 220R again, notices it is
before the start if window, silently
ignores it.

Tries to start 3 new exchanges

Allocating message ID, getting ID 221
Puts message ID 221 to window:
OWindow = (221, empty), start = 221

Allocating message ID, getting ID 222
Puts message ID 222 to window:
OWindow = (221, 222), start = 221

Allocating message ID, getting error
as there is no space in the window,
postpones the new exchange until there is
space in window.

sends 221 and 222

221 ->
222 ->
		< packets get reordered by network >

			  		Receives 222, slides the
					window, and stores the packet.
					Notices that there is one
					packet missing, but as this
					jump was less than window size
					then this is ok.

					IWindow = (empty, 222), start = 221

					Generates reply to 222

					Stores reply to RWindow, after
					sliding it forward

					RWindow = (empty, 222R), start = 221

					<- 222R

Gets 222R, marks it done in OWindow,
cannot slide window as it haven't
received 221R yet, so cannot start new
exchanges.

OWindow = (221, done), start = 221

					Receives 221, no need to slide
					window (already done during
					222), stores the packet.

					IWindow = (221, 222), start = 221

					Generates reply to 221

					Stores reply to RWindow

					RWindow = (221R, 222R), start = 221

					<- 221R

Gets 221R, marks it done in OWindow,
slides window forward, sliding also
over other done items.
OWindow = (empty,empty), start = 223

Notices, that now he can start new
exchange that was postponed earlier,
so restarts that exchange.

The IWindow and RWindow can also be combined, so that it has slots for
input and output packets for each message id. The OWindow does not
need that as it only stores one packet there, but it needs few status
bits, i.e. one marking that slot is empty (free to be allocated), and
one to mark that slot is done (no need to store the packet anymore).

The IWindow does not need to store full packets, as it can also store
only the hash of the input packet, as it is only used to verify that
the packet is same retransmission than the previous one. The
initialization is little bit special, as there can be multiple message
ID 0 in the exchanges, but after the initialization the message ID 0
is not special case any more..

First sending normal IKE_SA_INIT packet, getting COOKIE notify back
(as message ID 0), sending IKE_SA_INIT packet with COOKIE notify,
getting INVALID_KE_PAYLOAD notify back (as message ID 0), sending
IKE_SA_INIT packet with COOKIE notify and with another group, and then
getting the IKE_SA_INIT reply back (as message ID 0).

In initiator this is handled so that every time we start from the
beginning after getting notify (COOKIE, INVALID_KE_PAYLOAD) we clear
the OWindow completely, i.e. empty it and mark start to 0.

In the responder there is not problem, as when it is sending the
errors it will always simply send the error, and forget about the IKE
SA completely (it does not even allocate SPIr for the SA). As it
forgets the previous exchange completley, it will  not have any
IWindow or RWindow state which could mess up things.

There will be separate OWindow, IWindow and RWindow in both
directions. Note also that responder cannot really ever remove data
from its IWindow and RWindow. By the spec the initiator can wait for
one hour and then retransmit its message that is still in the window
and assume to get reply back.

Also there is problem that shrinking the window would be very hard. As
the notify will tell how many items can be send to you, the other end
might have too many exchanges out when it receives your shrink notify.

It could at that point postpone processing of the shrink request until
it has received enough responses so it can shrink its OWindow, and
only after that continue sending the reply to shrink request (but it
cannot include its own window size shrink in the reply message, as
otherwise the initiator do not have option to wait until the window is
small enough).

Because of this I think it would be best to say in the IKEv2 document
that window can only be enlarged by notify, not shrinken. Also we need
to define what happens to the window size in the IKE SA rekey. I would
like to propose that the new rekeyed IKE SA is started so that window
size is reset to 1 after the rekey (for the new IKE SA). This would
allow easy shrinking of the window size, by rekeying. After the rekey
the deletation of old IKE SA should be delayed until there is no more
exchanges out in either direction. 
-- 
[email-masked]

---

From: Surya Batchu <[email-masked]>
Date: Fri, 4 Mar 2005 10:27:17 -0800 (PST)

I undestand that the draft specification does not allow this. What is the problem in accepting new message ID, as long as message ID value is not less than the expected sequence number.  New message ID can be treated as right edge of window and adjust the window accordingly. 

Surya

---

From: Surya Batchu <[email-masked]>
Date: Fri, 4 Mar 2005 10:37:47 -0800 (PST)

It looks like, SA flood situation is not avoidable with the current limitations in specifications. It is up to the implementations to come out with proper methods to control the SA flood. Is that right?
 
Surya

Saroop Mathur writes:
> --- Tero Kivinen wrote:

---

From: Surya Batchu <[email-masked]>
Date: Sat, 5 Mar 2005 20:34:00 -0800 (PST)

I see one need for window change as in IPsec anti-replay window. IPsec anti replay window changes with the sequence number, if its value is more than the right edge of window.
 
With strict windowing as defined in specifications, it makes it difficult to make IKEv2 work in high availability environment. 
 
Take an example of two VPN devices - one acting as active and another one acting as backup for the first one. If state-ful failover is required, then the active device needs to update the backup device with  IKEv2 state. IKEv2 SA creation and deletion are two obvious events that need to be synchronized with the backup device. Due to rigidity of specification in this aspect, IKEv2 state needs to be updated with every change in window. Even with the best effort, it is possible that window events may not get synchronized at the backup device. 
 
If windows change is possible, then backup device, (when master device fails) can start with higher message id and then onwards new transactions will  work fine. 
 
Comments?
 
Thanks
Surya

Surya

---------------------------------
Celebrate Yahoo!'s 10th Birthday! 
Yahoo! Netrospective: 100 Moments of the Web _______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com