Subject: comments on 2401bis-01 - SPD, selectors

From: Mark Duffy <[email-masked]>
Date: Tue, 02 Mar 2004 22:55:18 -0500

In draft-ietf-ipsec-rfc2401bis-01.txt sect. 4.4.1 (re the SPD):

1.  On page 17 it states: "The second choice [bypass] refers to traffic 
that is allowed to pass without additional IPsec protection."
   If an inbound packet is  received with IPsec protection (e.g ESP) but 
the SPD calls for "bypass" for that packet, should it be accepted or 
dropped?  I have always understood that it should be dropped.  But either 
way the document should make it explicit.

2.  On page 18:  "If IPsec processing is specified for an entry, a 
"populate from packet" (PFP) flag may be asserted for one or more of the 
selector types in the SPD entry. If present, the flag applies to all 
selectors of the indicated type in the outbound element of the pair."
   What is meant by "all selectors of the indicated type"?  Does that mean, 
all values in the lists of ranges for the given selector type?  What pair 
is being referred to?
   Would it be accurate to rephrase that second sentence as "... If 
asserted for a given selector type, the flag indicates that the SA to be 
created should take its value for that selector type from the value in the 
packet; otherwise the SA should takes its value(s) for that selector from 
the value(s) in the SPD entry."
   Shouldn't it further state that, in the non-PFP case, the actual 
selectors negotiated may be narrower than those in the SPD entry, depending 
on the SPD policy of the peer?

In sect 4.4.2 (selectors):

3.  On p. 20:  "Also, note that the source/destination port selectors may 
be labeled as "OPAQUE" to accommodate situations where these fields are 
inaccessible because of prior encryption or due to packet fragmentation."
   If the "prior encryption" here refers a packet that is an IPsec packet 
then the Next Layer Protocol for the packet will be AH or ESP and port 
selectors are *undefined* (not opaque) for such a packet, right?  This 
looks like a holdover from 2401 where AH and ESP were not considered next 
layer (transport) headers.  Can we change "because of prior encryption or 
due to packet fragmentation" to just "due to packet fragmentation"?

4.  On p. 20:  "Note: In a non-initial fragment, port values will not be 
available. If the SA requires a non-OPAQUE port value, an arriving fragment 
MUST be discarded."
   If the SA "requires" (allows) the port value ANY, shouldn't that match 
non-initial fragments?  In section 6 on p. 38 it states:  "fragments not 
containing port numbers may only match rules having port selectors of 
OPAQUE or "ANY".   Either p. 20 or p. 38 should be changed.
   IMO either ANY or OPAQUE should match non-initial fragments, so I'd 
suggest changing p. 20 to read  "Note: In a non-initial fragment, port 
values will not be available. If the SA requires a non-OPAQUE port value 
other than ANY, an arriving fragment MUST be discarded."

As an editorial comment, since selectors appear in both SPD and SAD 
entries, I would further reword that to not be SA-centric:  "Note: In a 
non-initial fragment, port values will not be available. If a port selector 
specifies a non-OPAQUE value other than ANY, it cannot match packets which 
are non-initial fragments."

Thanks, Mark

---

From: Stephen Kent <[email-masked]>
Date: Fri, 5 Mar 2004 12:13:46 -0500

At 22:55 -0500 3/2/04, Mark Duffy wrote:
>1.  On page 17 it states: "The second choice [bypass] refers to 
>traffic that is allowed to pass without additional IPsec protection."
>   If an inbound packet is  received with IPsec protection (e.g ESP) 
>but the SPD calls for "bypass" for that packet, should it be 
>accepted or dropped?  I have always understood that it should be 
>dropped.  But either way the document should make it explicit.

a packet will be dropped if it fails to match the selectors defined 
for the SA via which it was received.  the text above also will have 
the word "additional" removed.

>"populate from packet" (PFP) flag may be asserted for one or more of 
>the selector types in the SPD entry. If present, the flag applies to 
>all selectors of the indicated type in the outbound element of the 
>pair."
>   What is meant by "all selectors of the indicated type"?  Does that 
>mean, all values in the lists of ranges for the given selector type? 
>What pair is being referred to?

the selector types are: S/D IP address, protocol, S/D port, ICMP 
type/Code, and the mobility header stuff. the "pair" referred to here 
was notion of separate inbound vs. outbound directional entries. 
later discussion  showed that this is not an appropriate distinction 
for SPD-S entries.

>asserted for a given selector type, the flag indicates that the SA 
>to be created should take its value for that selector type from the 
>value in the packet; otherwise the SA should takes its value(s) for 
>that selector from the value(s) in the SPD entry."

yes, that's a better way to say it.

>selectors negotiated may be narrower than those in the SPD entry, 
>depending on the SPD policy of the peer?

yes, I think that is consistent with IKE v2, and we can add text to 
that effect.

>3.  On p. 20:  "Also, note that the source/destination port 
>selectors may be labeled as "OPAQUE" to accommodate situations where 
>these fields are inaccessible because of prior encryption or due to 
>packet fragmentation."
>   If the "prior encryption" here refers a packet that is an IPsec 
>packet then the Next Layer Protocol for the packet will be AH or ESP 
>and port selectors are *undefined* (not opaque) for such a packet, 
>right?  This looks like a holdover from 2401 where AH and ESP were 
>not considered next layer (transport) headers.  Can we change 
>"because of prior encryption or due to packet fragmentation" to just 
>"due to packet fragmentation"?

yes, it was a holdover from 2401 and needs to be updated.

>
>4.  On p. 20:  "Note: In a non-initial fragment, port values will 
>not be available. If the SA requires a non-OPAQUE port value, an 
>arriving fragment MUST be discarded."
>   If the SA "requires" (allows) the port value ANY, shouldn't that 
>match non-initial fragments?  In section 6 on p. 38 it states: 
>"fragments not containing port numbers may only match rules having 
>port selectors of OPAQUE or "ANY".   Either p. 20 or p. 38 should be 
>changed.
>   IMO either ANY or OPAQUE should match non-initial fragments, so 
>I'd suggest changing p. 20 to read  "Note: In a non-initial 
>fragment, port values will not be available. If the SA requires a 
>non-OPAQUE port value other than ANY, an arriving fragment MUST be 
>discarded."

I hope to send out a memo on fragmentation issues soon. one issue is 
whether to keep OPAQUE, which should be distinct from ANY. If so, 
then ANY would not match missing port fields, e.g., in a non-initial 
fragment.

>entries, I would further reword that to not be SA-centric:  "Note: 
>In a non-initial fragment, port values will not be available. If a 
>port selector specifies a non-OPAQUE value other than ANY, it cannot 
>match packets which are non-initial fragments."

good point.

Steve