[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