Re: Specification of tunnel/transport attribute in IKEv2

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   > => RFC 2401 says in section 5 "If no policy is found in the SPD that
   > matches the packet..." (this defines the default action). The whole
   > RFC 2401 suggests the key of the SPD is a traffic selector. So I disagree
   > with you (note RFC 2401 doesn't say the opposite too, i.e. your objection
   > is valid and IPsec implementors in trouble).
   
   I was confusing the issue by using "unspecified terminology". In my
   view we have two types of "selectors"
   
   - policy selectors (the ones in SPD)
   
   - traffic selectors (used in IKEv2 key negotiations and end up into
     SAD)
   
=> I have two concerns with that:
 - policy and traffic selectors have the same format (i.e. the only way
   to know if a selector is a policy or a traffic one is its "owner").
 - I know you'd like that IKEv2 TS are SAD selectors but there is *no*
   consensus about this point.

   The latter are just qualifiers that are associated with the negotiated
   SA's. And are *ONLY* needed to differentiate multiple SA's between
   same endpoints. Instead of "traffic selector", should probably use
   some other term to avoid confusion with the actual "traffic selectors"
   in the policy. 
   
   >    In above my policy selector is just "local-port=80", but if I have
   >    additional requirement that each connection should use own SA, then
   > 
   > => this should be allowed according to RFC 2401 but it seems some
   > implementations need a SPD entry by connection (?)...
   
   Yes, they only partial implementations of rfc-2401, most likely due to
   IKE limitations. RFC-2401 allows many things, which are not possible
   with IKE(v1).

=> I have no reason to not believe you but my problem is I can't find
an "open-source" implementation of IPsec which has more than partial
implementations. So I can't judge if your view can be implemented
(or how to implement it).

   I would like to have this mistake avoided by the next
   IKEv2, and one way of achieving this result is to remove all policy
   checking from the IKE.
   
=> IMHO this is not the good way because we'll only get more unpredicable
results...

   In my implementation...

=> is it an open-source one (in order to understand it)?
   
   > PS: I believe this is a result of the incredible confusion in RFC 2401 & co
   > about addresses in SAs. At the question how many addresses characterized
   > a SA, you can answer zero, one, two, three or four and find a reference
   > in a RFC or an I-D...
   
   To me there is no confusion in the SA itself. You have a packet, you
   extract the selector information from as defined in RFC-2401.

=> this is a traffic selector view: two (inner) addresses.

   There are only 3 addresses: src, dst and possible IPSEC tunnel address (SG
   address).

=> I believe the third address is the outer destination. IMHO you should
consider the outer source too because:
 - some stupid implementations will check it so you may not just pick up one.
 - IKE negociates SAs by pairs and the outer source is the destination
   of the second SA in the opposite way.

   If my policy says
   
      selector => protect by SG
   
   then for incoming packets I must also check that the packet actually
   came from SG (I'm not really sure whether this check is really giving
   us anything).

=> so your implementation does an unnecessary check (this check gives nothing
but removes many).

   However, this only applies to tunnels that are specified within the
   IPSEC itself.
   
=> so you finish by 4 addresses because of the tunnel mode.
Other answers are:
 - zero: draft-ietf-ipsec-esp-v3-02.txt inbound processing of unicasts
 - one: RFC 2401 inbound processing (and previous I-D for multicasts)
 - two: common sense / transport mode
 - three: your first answer and PF_KEY (RFC 2367, the source and destination
   are outer addresses, the optional proxy is the inner source)

   There may be some confusion about what the src and dst actually are,
   in presence of things like IPv6 home address option.
   
=> home address option, routing header, etc, don't introduce confusion
because their action is guided by their position. For instance
the home address option should be before any IPsec header, so in inbound
processing it is always processed before any IPsec header and IPsec can see
only the home address. The complexity exists only for policy on SGs
but RFC 2401 gives the details of the transport header chasing: the
procedure is to jump between headers using the next header field,
so the content of headers should *not* be interpreted by a SG.
(this point should be made clearer in the next 2401)

Regards

Francis.Dupont@enst-bretagne.fr