comments on 2401bis-01 - SPD, selectors

[Mark Duffy <mduffy@quarrytech.com>]

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