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

From: Karen Seo <[email-masked]>
Date: Thu, 16 Sep 2004 00:54:51 -0400

Folks,

We just submitted 2401bis-03 to the IETF publications folks.

Changes include:
	a. Resolution on how to handle fragments on the protected side
	   of the IPsec boundary -- We changed approaches 2 and 3 to
	   MAY and MAY.
	b. Addition of an Appendix with the rationale for (a)
	c. Resolution on how to handle ICMP
	d. Revision of the Appendix with the ASN.1 for an SPD entry
	e. Addition of PMTU handling
	f. Revision of the SPD/PFP/packet/SAD tables
	g. More text on the fields associated with Next Layer Protocols
	   --> ports, ICMP message type/code, Mobility header type
	h. Deletion of Appendix "Categorization of ICMP messages"
	i. Updating of "Differences from RFC 2401"
	j. Revision/updating of "References"
	k. Many formatting and clarification edits

Thank you,
Karen

PS I'll be out of town (without email) 9/16-19, back on Monday.

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

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 16 Sep 2004 08:55:48 -0700

>We just submitted 2401bis-03 to the IETF publications folks.

To give everyone a bit more time to see it, this draft is available 
now at 
<http://www.vpnc.org/ietf-ipsec/TEMP-draft-ietf-ipsec-rfc2401bis-03.txt>. 
That link will go away when the draft makes it to the official drafts 
directory.

--Paul Hoffman, Director
--VPN Consortium

---

From: Francis Dupont <[email-masked]>
Date: Wed, 29 Sep 2004 01:04:00 +0200

I've read the last version (draft-ietf-ipsec-rfc2401bis-03.txt)
and I have some questions/comments:
 - nowhere it is explained how from a SPD one can find the other
   endpoint to use in tunnel mode:
  * in 3.2 this is not in the parameters which can be specified through
    the SPD management paradigm
  * in 4.4.1 some parameters needed to effect the protection are
    not listed (examples finish by "etc.")
  * in 4.4.1.2 this is not in processing info
  * in 4.4.2.1 this is in the data items in the SAD
  * 4.4.3 (PAD) is clearly about peers but does not give the answer
  * 4.5.3 is better but does not provide a general solution:
   "an IPsec-supporting host or security
    gateway MUST have an administrative interface that allows the
    user/administrator to configure the address of one or more security
    gateways for ranges of destination addresses that require its use."
   what I am looking for is the specified way to bind an SPD entry
   to a peer address.
  * in appendix C this is not in the ASN.1 definition of an SPD entry
 Note this can become important for a correct operation of a MOBIKE protocol
 (these addresses could be updated so we should know where they are),
  so I'd like to get it fixed.

 - the second major issue is with the inbound processing (5.2, pages 50*).
   There is no lookup in the SPD similar to RFC 5.2.1 step 3 so no
   check similar to step 4:
           3. Find an incoming policy in the SPD that matches the
              packet.  This could be done, for example, by use of
              backpointers from the SAs to the SPD or by matching the
              packet's selectors (Inner Header if tunneled) against
              those of the policy entries in the SPD.

           4. Check whether the required IPsec processing has been
              applied, i.e., verify that the SA's found in (1) and (2)
              match the kind and order of SAs required by the policy
              found in (3).

              NOTE: The correct "matching" policy will not necessarily
              be the first inbound policy found.  If the check in (4)
              fails, steps (3) and (4) are repeated until all policy
              entries have been checked or until the check succeeds.

    If we assume the SPD is decorrelated we can get rid of the note.
    RFC2401bis SPD entries specify only one protection so the check
    should not be done at the end but each time (i.e., in the SAD check
    with SA "chaining" managed by loopback forwarding as shown in
    appendix E).
    My concern is the SAD check is not equivalent because of the
    SAD is not ordered and SAD selectors reflect SPD selectors at
    the time the SA is created, not the actual SPD situation.
    I give in the PS two examples of the issue.

 - in 4.1 matching on the SPI only works well when the SPI is given by
   one and only one node. Of course this can't be the case for multicast
   so we've got the destination+SPI or source+destination+SPI stuff.
   But 2nd paragraph associates the anycast case to the unicast one
   when the receiver in the anycast case is just a member of the group,
   and we can *not* assume to get the same member everytime.
   IMHO we have to deal with the anycast case as with the multicast case.
   (note that as an IPv6 man I understand "anycast" as "IPv6 anycast" :-)

 - in 4.1 lookup description (1, 2 and 3) the "ESP" seems superfluous.
   Some lines before, the draft states the protocol field is not used
   for multicast SA lookups without any explaination...

 - the initial fragment definition in 4.4 and use in 7 are not sound:
      "And the phrase "initial"
       fragment is used to mean a fragment that contains all the selector
       values needed for access control."
      "Also, for IPv6, even an initial fragment might NOT
       contain the Next Layer Protocol or Ports (or ICMP message type/code,
       or Mobility Header type) depending on the kind and number of
       extension headers present."
   with the definition there can be no initial fragment so the second
   statement doesn't make sense.

 - in 5.1 3b a "may" follows a "MAY"?

 - in 5.1.2.2 the flow label stuff is wrong: the flow label may be
   configured or automatically generated, *not* copied from the inner
   header. IMHO it is safe to assume than an SA is a flow.
   Of course the issue is worse in appendix C...

 - in 13 the draft states:
   o 2401bis clarifies that for all traffic that crosses the IPsec
      boundary, including IPsec management traffic, the SPD or
      associated caches must be consulted.
  This should be true, cf my first concern!

 - in references, Mobip is RFC 3775.

Thanks

[email-masked]

PS:
first example:
 we'd like to protect any traffic between A and B with AH
 (SPD rule 1 local=A remote=B NLP=ANY Action=PROTECT(AH))
 but for TCP we'd like confidentiality
 (SPD rule 2 local=A remote=B NLP=TCP Action=PROTECT(ESP))
If B sends to A a TCP packet protected by AH:
 - the SAD check will accept it (it matches the SA created by rule 1)
 - a SPD check will dropped it (incorrect protection).

second example:
 To avoid the first example case, the SPD can be decorrelated before
SAD selectors are filled. But this is not enough if the SPD is modified,
for instance if the rule 2 is inserted in the SPD after the rule 1.
Note I don't argue the SAD selectors should be modified, 4.4.2 is correct
("the entry for an inbound SA in the SAD MUST contain the value or
values negotiated at the time the SA was created.")
The real problem is the SAD check is not enough and must be followed
by a SPD check.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 30 Sep 2004 14:39:05 -0400

Francis,

Tunnel SA destination address: This was not present in 2401bis 
either, but we should  deal with it now.  We can add it to the SPD 
definition text and the ASN.1 in the appendix, and will make sure it 
is in the appropriate subsections of 4.4.  I don't see it being in 
the PAD.  4.5.3 says you have to make this info available, but does 
not say how, because we have no standard mechanism.  I think the best 
we can do is to augment the SPD definition to include the data and 
note that there is no standard means to do this.

checking inbound traffic (5.2): You provided an example at the end of 
your message to clarify the concern re checking only the SAD entry 
vs. checking the SPD. However, I do not understand your example. You 
specified the first entry in the SPD applying to ALL traffic, and 
thus a linear search of the SPD would match that rule first, 
overriding the second entry, which was TCP-specific and called for 
use of ESP. The entries would have to be reversed if the second entry 
would ever be applied. If the entries were reversed in order, then 
the TCP-specific rule would catch all TCP traffic, and all other 
traffic would have AH applied. When the SPD is decorrelated, that 
process would split the AH SPD entry, to avoid overlap with the ESP 
SPD entry. (Using the new selector range value, the AH entry could be 
expressed as two new entries, specifying the protocol number ranges 
below and above TCP.)  As a result, the SAD entry established for 
carriage of AH-protected traffic would not overlap with the 
TCP-specific SAD entry for which ESP must be applied. So, if a peer 
sent TCP traffic via the AH SA, it would NOT match the selectors in 
the SAD, since that SAD entry would have a gap where TCP would be.

inbound SA selection (4.1): We can move the allusion to anycast to 
the discussion of multicast if other agree. We took text supplied by 
another WG member to more precisely describe this aspect of 
processing and this is the first time it has appeared in a draft. The 
references to ESP in the processing steps here are superfluous and 
will be removed.  the protocol field is not used in SA selection for 
multicast SAs because support for such SAs is new, and we retained 
the option of using the protocol field as an option only for backward 
compatibility for unicast SAs.

initial, non-initial, and first fragments: The definition in 4.4 is 
correct, noting that in some cases in IPv6, the initial fragment 
might not be the first fragment. The text in 7 will be changed to 
match that in 4.4, specifically we will change "Also, for IPv6, even 
an initial fragment might NOT contain the Next Layer Protocol or 
Ports ..." to say "Also, for IPv6, the first fragment might NOT 
contain the Next Layer Protocol or Ports ..."

5.1 3b: We will fix the lowercase "may" in this section.

5.1.2.2: other than for covert channel concerns, why would one never 
copy a flow label from the inner header?

13: the SAD is a form of SPD cache, for inbound traffic carried via 
an SA.  do you think we need to clarify this in the discussion of the 
SAD in 4.4.2?

we will update the reference to the Mobile IP RFC

---

From: Francis Dupont <[email-masked]>
Date: Thu, 30 Sep 2004 22:10:47 +0200

In your previous mail you wrote:

=> I agree but we should do something for the Tunnel SA source address too:
 - to be coherent with the situation on the peer where source and
   destination address roles are swapped
 - because if in many cases the source address can be inferred from the
   destination address this is not always the case.
So I proposed an optional field when no value means infer from the
destination.

=> I forgot to specify the order of the rule: the most specific must
be first.

=> please assume the reversed order.

=> when? This is not clear that the SPD is decorrelated... I am afraid
the decorrelation goal is to focused on caching so I missed in 5:
   Note: It is assumed that one starts with a correlated SPD...

=> 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).

   ... other little points...

=> fine

=> in order to break the unicity rule on flow labels? IMHO the flow
label MUST NOT be copied.

=> yes because there is a good way to not reproduce pages of explainations
about how to manage SAD selectors for instance about changes implied by
add/update/delete in the SPD.

Thanks

---

From: Stephen Kent <[email-masked]>
Date: Thu, 30 Sep 2004 16:42:37 -0400

>So I proposed an optional field when no value means infer from the

the source address, for the sender, is trivial if you have just one 
interface, and if you are  not mobile. if you have multiple 
interfaces, you do need to specify the right one to use as the source 
address, statically. if you are mobile, you need to have something 
outside of IPsec updating the value, which says that there would not 
be any useful SPD entry to specify in advance. so, yes, we will add 
text to accommodate both source and destination addresses for tunnel 
headers.

	<SNIP>

>the decorrelation goal is to focused on caching so I missed in 5:

we do not explain how to perform decorrelation in detail the text, 
but rather refer to Appendix B. A fundamental requirement for any 
algorithm of this sort is that it breaks overlapping entries into 
non-overlapping entries. I think the text inn 4.4.1 says that 
reasonably well.

>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.

>label MUST NOT be copied.

what is the "unicity rule?"

Steve

---

From: Francis Dupont <[email-masked]>
Date: Fri, 01 Oct 2004 01:31:05 +0200

the source address, for the sender, is trivial if you have just one 
   interface, and if you are  not mobile. if you have multiple 
   interfaces, you do need to specify the right one to use as the source 
   address, statically.
   if you are mobile, you need to have something outside of IPsec
   updating the value,

=> an IPsec/mobile integrate code needs to know the place of the value
to be enabled to update it: I raised the issue exactly for this reason...

   which says that there would not 
   be any useful SPD entry to specify in advance. so, yes, we will add 
   text to accommodate both source and destination addresses for tunnel 
   headers.
   
=> so this issue is closed.

   
=> 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.

   

   
=> 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!)

   
=> 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.

Thanks

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.