Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec
jouni korhonen <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
Few things. The draft already states that "The Padding, Pad Length, Next Header and ICV fields follow the rules of Section 2.4 to 2.8 of [RFC4303] unless otherwise stated in this document." So, we follow the ESP format but feel no shame on changing it if we see a reason to do so. The reason why we chose to do it like this was two fold: 1) some ciphers etc when used would need ~equivalent encapsulation anyway. 2) if we had come up with our very own format the question on the list would have been "why not using RFC4303 encapsulation format". Actually.. the latter already happened offline. - Jouni On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: > Hi Raj, > >> Inline: >> >> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <[email protected]> wrote: >> >>> >>> To me, what the draft describes is a patchwork based on MIPv6, ESP and >>> TLS. Instead of building on top of those protocols (read modularity >> and >>> interoperability), it reuses (hijacks) various blocks of associated >>> standards in a non-modular way. For instance, one has to reimplement >> ESP >>> in userspace to support the protocol. >> >> We are specifying an encapsulation method in the I-D. To say that one >> has to reimplement ESP in userspace is incorrect. > > The encapsulation format you have in the I-D is: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > : UDP header (src-port=Xp,dst-port=Yp) : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ > |PType=8| SPI | ^Int. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- > | Sequence Number | |ered > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- > | Payload Data* (variable) | | ^ > : : | | > | | |Conf. > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- > | | Padding (0-255 bytes) | |ered* > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | > | | Pad Length | Next Header | v v > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ > | Integrity Check Value-ICV (variable) | > : : > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 7: UDP Encapsulated Binding Management Message Format > > Which looks like a copy/paste of the ESP specification [RFC4303]: > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---- > | Security Parameters Index (SPI) | ^Int. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- > | Sequence Number | |ered > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ---- > | Payload Data* (variable) | | ^ > ~ ~ | | > | | |Conf. > + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Cov- > | | Padding (0-255 bytes) | |ered* > +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | > | | Pad Length | Next Header | v v > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ------ > | Integrity Check Value-ICV (variable) | > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 1. Top-Level Format of an ESP Packet > > > So the question is: Is your intent to provide a UDP encapsulation format for the already specified ESP protocol, or to provide an alternative encapsulation format to ESP? > > --julien > _______________________________________________ > MEXT mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mext