Thanks Tero. Good catches. We'll address them in the upcoming revision. > -----Original Message----- > From: Tero Kivinen [mailto:kivi...@iki.fi] > Sent: Monday, 24 August, 2009 6:03 AM > To: ipsec@ietf.org > Cc: draft-ietf-ipsecme-traffic-visibil...@tools.ietf.org; ipsecme- > cha...@tools.ietf.org > Subject: draft-ietf-ipsecme-traffic-visibility-07.txt comments > > I now finished reading that traffic visibility draft and I have some > minor nits for it. > > In section 2, when describing flags, it does not explictly give the > bit order used when describing bits. I.e. is the version in bits 24-25 > in the full 4-byte header, or bits 30-31. > > Adding those fields to the picture would make this clear, i.e. > changing the Detailed WESP Packet Format picture to be: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Next Header | HdrLen | TrailerLen |V|V|I| Flags | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Existing ESP Encapsulation | > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Or adding separate picture for flags, or adding similar text than what > is in RFC4306 ("The bits are defined LSB first, so bit 0 would be the > least significant bit of the Flags octet). > > Also in section 2 it says "2 bits: Version. MUST be sent as 0 and > checked by the receiver. ", i.e. the version bit must be checked by > the receiver, but it does not say what needs to be done if the version > is different (most likely packet should be dropped, as version should > have be negotiated already in the IKEv2). > > In the end of section 2 (second last paragraph) there is sentence > saying "The receiver MUST drop packets for which the integrity check > is invalid.". > > I think this sentence is confusing, as if it means that receiver must > check the ICV field as normally IPsec, I do not think there is any > need to say that again, as it is clear from normal IPsec processing, > that packets with incorrect ICV are dropped. Especially as this is > just after text about future versions of protocol, I first read it and > started wandering if there is some separate integrity check that needs > to be done or what. > > In section 4. IANA Considerations it says that: > > The final 6 bits of the WESP Flags are the "Non-version Flags". > This specification defines no values, and future assignment is to > be managed via the IANA Policy of "Specification Required". > > This is not correct, as it already defines one more bit, i.e. the > "Encrypted Payload" bit in this document. > -- > kivi...@iki.fi
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
