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

SOI QUESTION: 5.1, 5.1.2, 5.2, 5.3, 6, 6.1, 6.2



> 5. SA creation style
> 5.1 Cryptographic agreement
> 5.1.A)Is negotiation for the algorithm suite required or not?

Yes. 

> 5.1.B) Is there ever a case when you want the initiator to have the "last 
> word"?

Initiator will always have the last word. It can simply just not use
the SA created... I think that is enough for the initiator... 

> 5.1.2 Agreement of IPsec SA cryptographic algorithms
> 5.1.2.A) Is it important to allow negotiation of the SA algorithms?

Yes.

> 5.2 Scope of proposals
> 5.2.A) Is it important to have predefined suites or a la carte selection of 
> parameters?

I like a better to have GUI suites and a la carte selection of
algorithms inside the protocol. I myself think that a la carte
selection is easier to implement and it will simplify the debugging,
extensibility of the protocol and protocol specification itself, and
it does not affect the implementation that much.

The reason it is easier to debug is that for example our TLS library
has 41 differnet suites now. Some of those are pretty wierd and I am
not sure if anybody has tested them against someone else ever. We have
tested them against ourselves, but that does not show problems like we
had typo in the suite definiation once and that was found out few
years after when someone had some wierd client actually using that
suite...

Testing 41 different suites manually is quite much work, and in that
case you are going to implement test program to test them all
automatically. If you are testing them automatically then it really
doesn't matter if there is 41 or 100000 of them. For example my test
program for isakmp by default test about 300 combinations, and given
suitable parameters it will test all cipher sa combinations (2
exchange methods * 4 authentication methods * 11 ciphers * 4 hash
algorithms * 8 groups * 6 cipher lengths = 2816 tests). Adding even
more parameters it starts testing with different identity types etc
and that will end up having about 100000 tests...

So I think the number of suites is going to be too big for manual
testing anyways and if you test them automatically it really doesn't
matter how many of them there are.

Also as I said we have now 41 different suites in the TLS library, but
I don't know if that is up to date list. We might be missing some and
when someone decides to add new suite like AES + MD5 then we need to
update the suite list again to get them working. If the TLS would use
the similar combinatory system the AES + MD5 would just simply work
automatically, because we have both AES and MD5 support there
already.

> 5.3 SPD entries
> 5.3.A) Is it important in SOI to allow the the responder to accept a subset 
> of the proposed SA, or should it be an all or nothing acceptance?

Yes. It makes it easier if the both ends does not have to agree about
the policy completely beforehand, thus if we can get it automatically
recover for that kind of misconfigurations it is good... (i.e other
end configure 192.168.0.0/16 and other end 196.168.2.0/256). 

> 5.3.B) Should the SOI offer multiple selectors with specific ports and
> addresses, or a single selector with a range of ports and range of
> addresses?  (complicated boolean complexity!)  

I think the list of ranges as an only form is best.

> 6. Wire protocol issues
> 6.1 Message encoding
> 6.1.A) Should SOI worry about aligning parts of messages on 2 and 4
> byte boundaries?

No. Compared to encryption/decryption and Diffie-Hellman the
misaligned data access doesn't really matter. Also the IKE packets are
not sent or received that often. Adding padding after variable length
data simply adds quite a lot of code and that normally means bugs. 

> 6.1.B)  Should SOI tag its protocol with version numbers?

Yes. 

> 6.1.C) Should SOI format be roughly the same as IKEv1?  (See
> discussion in section 6.4, re: code preserving)

I think yes. There isn't actually anything that bad or complex in the
basic packet/payload encoding. 

> 6.2 Port number
> 6.2.A) Should SOI use the same port as IKEv1?  (See discussion in
> soi-features-01 the tradeoffs in this question).

If the packet format is similar than IKEv1 then I think we should use
the same port as it allows implementations supporting both versions
faster fall back to old version (provided that the other end sends
error notification when it receives IKEv2 packet).
-- 
kivinen@ssh.fi
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/