Re: Adding revised identities to IKEv2

[Michael Thomas <mat@cisco.com>]

Uri Blumenthal writes:
 > At 10:35 11/15/2002 -0800, Michael Thomas wrote:
 > >1) Credentials are verified, 2) Authorization is applied given the policy in
 > >the SPD -- for IPsec, this means setting up ... parameters on the receiver
 > >  side...*may*  or *may* *not* have anything to do with the source IP address
 > >3) packets are ....checked, classified and run through ......#2........
 > >
 > >All of this should be *independent* of the IP address the key management
 > >protocol is being run on, and in fact should be completely separable.
 > 
 > Ah, with this I agree. I think you mean: not IP address but SA itself is 
 > validated
 > by crypto signatures. That's fine.
 > 
 > Except that to the best of my knowledge, IP addresses are part of SA 
 > information,
 > i.e. filtering is done NOT based solely on SPI...

To be pedantic...

There are two things going on: first is SADB
lookup for the incoming packet. I believe that
Steve a while back said that it is currently
SPI+DSTaddr, but that in revisions it would only
be SPI unless DSTaddr is a multicast address in
which case it would be SPI+DSTaddr as now. There's
never been a requirement for SRCaddr that I'm
aware of if implementations (mistakenly, IMO)
often do use it as part of the lookup operation.

The second is the classification/filtering
operation after the packet is integrity checked.
This is just the normal 5-tuple filtering which
may or may not pay attention to the source address
(ie, it could be wildcarded).

 > And replying to Francis - I'm too lazy to check myself, but wasn't cookie 
 > (which is
 > IP address-based) used then as a part of signed contents in IKEv1 exchange?


Right... if it's true, we really need to fix this
in IKEv2 (if it's not already fixed). IKE qua
protocol should be completely independent of which
src address the message originated from. Anything
that breaks that requirement needs to be fixed.

	    Mike