Subject: [IPsec] draft-ietf-ipsecme-traffic-visibility-07.txt comments

From: Tero Kivinen <[email-masked]>
Date: Mon, 24 Aug 2009 16:03:11 +0300

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. 
-- 
[email-masked]

---

From: Gabriel Montenegro <[email-masked]>
Date: Wed, 26 Aug 2009 10:29:53 +0000

Thanks Tero. Good catches. We'll address them in the upcoming revision.

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]]
> Sent: Monday, 24 August, 2009 6:03 AM
> To: [email-masked]
> Cc: [email-masked]; ipsecme-
> [email-masked]
> Subject: draft-ietf-ipsecme-traffic-visibility-07.txt comments
>