[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Comments on IKEv2

  Valery, zdrastii!

On Fri, 07 Dec 2001 11:05:05 +0300 you wrote
> 
> on what criteria could responder base his decision to narrow TS? 
> Assume the following situation: initiator offers wildcard TSS, while 
> responder's SPD consists of several adjacent ranges. The very natural 
> decision for him is to select and sent back to initiator one of these 
> ranges. But which? He doesn't have enough information because 
> initiator has no ability to tell him what exact packet she is trying 
> to make SA for. If this information were provided by initiator (via 
> special payload or by requiring the first TSS in TS to always 
> represent the actual IP packet triggered this negotiation), this 
> would increase robustness of the protocol.

  The Responder could send back all of them. If the packet that
triggered the Initiator's negotiation was not included in what the
Responder sent back then those packets would not be sent after
negotiation for the subset succeeded (I'd imagine that if the
Initiator is a gateway it would send back some "administratively
prohibited by filter" message back to the source). But that is what
happens when the Responder does not allow the Initiator to access
what she (the Initiator) wants to access. No way around that.

  Requiring the first TSS in the TS to always represent the actual
IP packet triggering the negotiation is an interesting idea but it
wouldn't solve the problem you described-- the packet matched a
wildcard selector. Or are you suggesting that no negotiation should
succeed? That is, the Responder says "no proposal chosen" instead
of sending back a TS subset?

> And one more comment. The peers seem to have no ability to inform 
> each other about what kind of signature (RSA or DSA) they will use. 
> Why so? This will require all implementation to support both (or even 
> more if ECDSA come later) to be interoperable. Wouldn't it be better 
> to negotiate this, as well as cipher, hash and group?

  Can't you infer what signature the peer supports? If you are
using a pre-shared public key you know directly. If you are enrolled
in a CA you should know what types of certs it will issue, no? If
it issues certs for both RSA and DSA public keys then you have to
support them both. If it issue certs for just one then you just have
to support that one. I would imagine that people want to make their
product as versatile as possible, though, and support them both
regardless of whether a magic number is used to indicate up-front
which signature will be used. 

  Dan.
Follow-Ups: References: