[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
V2 - Structuring SA proposals
RE: PF_key v2·
I dont like/understand why/disagree with there being two extensions
to achieve one objective - that of prioritising algorithms - this is effectively
what the ASSOCIATION EXT and the PROPOSAL EXT achieve.
Would it be better to have something like the following :-
NOTE: alignment being ignored ;-)
Base Header:
struct sadb_msg {
uint8_t sadb_msg_version;
uint8_t sadb_msg_type;
uint8_t sadb_msg_errno;
uint8_t sadb_sa_type;
uint8_t sadb_sa_state;
uint8_t sadb_sa_spi;
uint16_t sadb_msg_len;
uint32_t sadb_msg_seq;
uint32_t sadb_msg_pid;
}
Proposal Extension:
struct sadb_prop {
uint16_t sadb_prop_len;
uint16_t sadb_prop_num_combs;
uint16_t sadb_prop_replay; (cant flags indicate we want replay ?)
uint16_t sadb_prop_flags;
}
Combination Extension:
struct sadb_comb{
uint8_t sadb_comb_num;
uint8_t sadb_comb_len;
uint8_t sadb_comb_auth;
uint8_t sadb_comb_encr;
uint16_t sadb_comb_auth_keylen_min;
uint16_t sadb_comb_auth_keylen_max;
uint16_t sadb_comb_encr_keylen_min;
uint16_t sadb_comb_encr_keylen_max;
}
Elfed
****************************************************
Elfed T. Weaver
Defence Evaluation & Research Agency
Malvern
UK
+44 01684 894795
weaver@hydra.dra.hmg.gb