1*3f664eb9Sjmc$OpenBSD: QUESTIONS,v 1.5 2003/11/05 12:31:21 jmc Exp $ 201f1f88eSniklas$EOM: QUESTIONS,v 1.12 1998/10/11 17:11:06 niklas Exp $ 32040585eSniklas 42040585eSniklasDoes the spec limit the count of SA payloads in a message? Where if so? 52040585eSniklas[ Only the specific IKE main mode does. In the IKE spec.] 62040585eSniklas 72040585eSniklasThe message ID field of the header, can it be considered a SA identifier 82040585eSniklasif used together with the cookiepair? [Yes, it is meant to be that] 92040585eSniklas 102040585eSniklasDOI 0, what protocols are defined for it? Where? 112040585eSniklas 122040585eSniklasIsn't this a potential DOS attack: 132040585eSniklasHostile user listens for ISAKMP traffic, and then extracts cookiepairs 142040585eSniklasand message IDs which he uses to flood any of the peers with spoofed 152040585eSniklaspackets pretending to be the other one. Most probably these packets will 162040585eSniklasresult in error notifications which potentially result in SA tear-down? 172040585eSniklasMaybe should notifications never be issued for erroneous packets which 182040585eSniklascannot be authenticated? Or should we not tear down SAs as results of 192040585eSniklasnotifications? 202040585eSniklas 212040585eSniklasCerticom claims to hold licenses for Elliptic Curve Cryptography? Does this 22*3f664eb9Sjmcconcern us? See: http://grouper.ieee.org/groups/1363/P1363/patents.html 232040585eSniklas 242040585eSniklasMain mode when using public key encryption authentication does not look 252040585eSniklaslike an identity protection exchange to me. Must I really get rid of 262040585eSniklasthe generic ISAKMP payload presense tests? 272040585eSniklas 282040585eSniklasIV generation is not described precisely in Appendix B of -oakley-08.txt: 292040585eSniklas'Subsequent messages MUST use the last CBC encryption block from the previous 302040585eSniklasmessage as their IV'. This probably means that we take the new IV from the 312040585eSniklaslast encrypted block of the last message we sent. The SSH testing site uses 322040585eSniklasthe last block from the last message they received. This is probably not 332040585eSniklaswhat was meant and should be clarified on ipsec@tis.com. 342040585eSniklas[ From what we have gathered this is what is meant. ] 35