Subject: Re: [Ipsec] revised IPsec Architecture draft (2401bis)

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Oct 2004 10:05:48 -0400

Francis,

>=> I have no problem with the decorrelation idea (I began with pattern
>matching and term rewriting systems where the problem is hard, BTW
>IMHO decorrelation is related to completion, i.e., Knuth-Bendix algorithm).
>  But I still believe a statement explaining the SPD is considered as
>being decorrelated after the end of 4.4.1 should be fine.
>
>    >=> so the SAD check works for the first example but not (yet) for the
>    >second where the rule 2 is added* after the creation of the SAD entry
>    >for the rule 1 (*: after in time, before in order).
>   
>    section 4.4.1 concludes with a brief section:
>   
>   	Handling Changes to the SPD while the System is Running
>   
>   	If a change is made to the SPD while the system is running, a check
>   	SHOULD be made of the effect of this change on extant SAs. An
>   	implementation MAY choose to check the impact of an SPD change on
>   	extant SAs and to provide a user/administrator with a mechanism for
>   	configuring what actions to take, e.g., delete an affected SA, allow
>   	an affected SA to continue unchanged, etc.
>   
>    i think this addressed your concern.
>   
>=> yes but this conflicts with the end of 4.4.2:
>
>    For each of the selectors defined in Section 4.4.1.1, the entry for
>    an inbound SA in the SAD MUST contain the value or values negotiated
>    at the time the SA was created. For a receiver, these values are used
>    to check that the header fields of an inbound packet (after IPsec
>    processing) match the selector values negotiated for the SA. For the
>    receiver, this is part of verifying that a packet arriving on an SA
>    is consistent with the policy for the SA. (See Section 6 for rules
>    for ICMP messages.)  These fields can have the form of specific
>    values, ranges, ANY, or OPAQUE, as described in section 4.4.1.1,
>    "Selectors."
>
>(note I like the idea of explaining that the SAD selectors are in fact
>the inbound SPD cache!)

We will note explicitly that the SAD acts as a cache for selector 
checking for inbound traffic on SAs.  However, I do not see why you 
feel that the 4.4.2 text conflicts with the text at the end of 4.4.1. 
The 4.4.2 text is a steady state discussion of processing. The text 
at the end of 4.4.1 is an exception processing discussion.

>
>    >     5.1.2.2: other than for covert channel concerns, why would one never
>    >    copy a flow label from the inner header?
>    >  
>    >=> in order to break the unicity rule on flow labels? IMHO the flow
>    >label MUST NOT be copied.
>   
>    what is the "unicity rule?"
>   
>=> RFC 3697 section 3 (flow labeling requirements):
>
>    A source node MUST ensure that it does not unintentionally reuse Flow
>    Label values it is currently using or has recently used when creating
>    new flows.  Flow Label values previously used with a specific pair of
>    source and destination addresses MUST NOT be assigned to new flows
>    with the same address pair within 120 seconds of the termination of
>    the previous flow.
>
>Obviously RFC 3697 requires the source node has the control of label
>assignment and bans SGs from copying flow labels from inner headers.

OK, I see the problem now. The SG, if it copied flow labels could 
cause collisions because it appears as the new source and the sources 
behind it might use the same flow label for their own flows.

>PS: about flow labels IMHO it is enough to refer to RFC 3697.
>The only issue is the RFC 3697 doesn't really define flows:
>
>    A flow is a sequence of packets sent from a particular source to a
>    particular unicast, anycast, or multicast destination that the source
>    desires to label as a flow.  A flow could consist of all packets in a
>    specific transport connection or a media stream.  However, a flow is
>    not necessarily 1:1 mapped to a transport connection.
>
>I believe we can say:
>  - a SA can form a flow (default case)
>  - multiple instances of SAs with the same parameters can form a flow
>    (at least two reasons: keep the same flow label across rekeying,
>     allow explicit specification of flow label values)
>so we get:
>  - zero flow label
>  - explicit specification (which includes previous case)
>  - automatic assignment by the IPv6 according to its own flow establishment
>    method (i.e., don't care at the IPsec level :-)
>This can be encoded by an optional value on 20 bits.

OK.

Steve

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

---

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Oct 2004 18:07:06 +0200

We will note explicitly that the SAD acts as a cache for selector 
   checking for inbound traffic on SAs.

=> fine.

   However, I do not see why you 
   feel that the 4.4.2 text conflicts with the text at the end of 4.4.1. 

=> a possible action of the end of 4.4.1 is to update the selectors of
an affected SA, this is forbiden by the MUST of 4.4.2. IMHO the problem
is in the wording, i.e., "contain" should be changed by "be filled by"
or something else catching the idea the selectors are dynamic and
*always* reflect the SPD as a cache does.

Thanks

[email-masked]

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Fri, 1 Oct 2004 10:37:42 -0700

Steve,

I just had one minor comment about the decorrelation part below.
> checking for inbound traffic on SAs.  However, I do not see why you 

Yes, this would help. Note that at end of section 5 there is already some text

   For inbound IPsec traffic, the SAD entry selected by the SPI serves
   as the cache for the selectors to be matched against arriving IPsec
   packets, after AH or ESP processing has been performed.

But still there could be some extra clarification in the section where Decorrelation
is defined. It talks about how it is not needed for host implementations where
sockets can be used for caching. Perhaps, some text there would help i guess.

The other possibility is to also mention that if decorrelation is not done, then
SPD should be checked explicitly. This will make it easy and useful for 
implementers who have not implemented decorrelation (also for folks who
are used to RFC 2401 and transitioning to 2401bis).

-mohan

---

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Oct 2004 16:30:17 -0400

Francis,
>*always* reflect the SPD as a cache does.

I see your point. The phrase "the SAD MUST contain the value or 
values  negotiated at the time the SA was created" is the sticking 
point. We will reword that to reflect the possibility that the SAD 
entry was updated as a result of an SPD change.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Oct 2004 17:59:44 -0400

Mohan,
	<SNIP>
>are used to RFC 2401 and transitioning to 2401bis).

I am happy to refine the discussion of decorrelation and make the 
change that Francis noted at the end of 4.4.2. But, we chose to adopt 
the decorrelation model as the basis for explaining IPsec processing 
because it simplifies the discussion overall, allowing caching. I do 
not want to go back and try to accommodate non-decorrelated 
processing in the model.  The exception, which we note and that you 
cited, is that native host implementations need not decorrelate the 
SPD because they implicitly perform caching.

Steve

---

From: Mark Duffy <[email-masked]>
Date: Mon, 04 Oct 2004 12:55:30 -0400

Hi Steve, please see comment below...

At 05:59 PM 10/1/2004, Stephen Kent wrote:
[snip]
>I am happy to refine the discussion of decorrelation and make the change 
>that Francis noted at the end of 4.4.2. But, we chose to adopt the 
>decorrelation model as the basis for explaining IPsec processing because 
>it simplifies the discussion overall, allowing caching. I do not want to 
>go back and try to accommodate non-decorrelated processing in the model.

The above statement about accommodating non-decorrelated processing got me 
concerned.  It is my understanding that the decorrelated SPD is meant 
mainly as a model for describing the behavior, and possibly as an 
implementation hint.  It is also my understanding that implementations 
based on an ordered (non-decorrelated) SPD are still to be "accommodated" 
in the sense that they can fulfill the requirements of the protocol.

Can you confirm this?  By not "accommodating" the 
non-decorrelated  approach do you mean not describing it in the document, 
or not caring about whether it can be used as an implementation 
technique?  I hope it is the former.

Thanks, Mark

>   The exception, which we note and that you cited, is that native host 
> implementations need not decorrelate the SPD because they implicitly 
> perform caching.
>
>Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 4 Oct 2004 14:09:59 -0400

At 12:55 PM -0400 10/4/04, Mark Duffy wrote:
>>change that Francis noted at the end of 4.4.2. But, we chose to 
>>adopt the decorrelation model as the basis for explaining IPsec 
>>processing because it simplifies the discussion overall, allowing 
>>caching. I do not want to go back and try to accommodate 
>>non-decorrelated processing in the model.
>
>The above statement about accommodating non-decorrelated processing 
>got me concerned.  It is my understanding that the decorrelated SPD 
>is meant mainly as a model for describing the behavior, and possibly 
>as an implementation hint.  It is also my understanding that 
>implementations based on an ordered (non-decorrelated) SPD are still 
>to be "accommodated" in the sense that they can fulfill the 
>requirements of the protocol.
>
>Can you confirm this?  By not "accommodating" the non-decorrelated 
>approach do you mean not describing it in the document, or not 
>caring about whether it can be used as an implementation technique? 
>I hope it is the former.

correlated SPDs are in no way prohibited in 2401bis. it's just that 
we have found it much easier to describe processing based on a 
decorrelated SPD. in fact, we have cited places where one has to be 
careful to mimic the behavior of a correlated SPD implementation, if 
one uses a decorrelated SPD, so I think this says that we are not 
ruling out correlated SPD implementations.

however, the 2401 processing model contained a mix of assumptions, 
some of which relate to use of a correlated SPD, and others that do 
not. in this case, the call to search the SPD to find matching 
entries was always a problematic aspect of the processing 
description, and so getting rid of it is appropriate, given that we 
no longer support nested SAs, for example.

Steve

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Mon, 4 Oct 2004 13:07:04 -0700

> SPD because they implicitly perform caching.
I am fine with this. It would avoid a lot of questions in the future if we can
state explicitly that (in the decorrelation definition) SAs are used for caching
the selectors and is the same as referring to the SPD that it is cached from
(or some such thing).

Thanks
mohan