Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec
Jouni <[email protected]>
| Newsgroups | gmane.ietf.nemo |
|---|---|
| Message-ID | <[email protected]> |
Just a question for my clarification. Do you mean simply taking the UDP encap + ESP format or also inheriting everything those respective RFCs say about their processing etc? - JOuni On Jan 28, 2011, at 9:18 PM, Laganier, Julien wrote: > Hello again, > > Thought that maybe making my question a bit more specific would help: > > So, why don't you simply define a UDP encapsulation to ESP, instead of duplicating ESP functionality into your framework? > > --julien > > Laganier, Julien wrote: >> >> Hi Jouni, >> >> I understand you "follow the ESP format but feel no shame on changing >> it if we see a reason to do so", but I am (shamelessly ;) wondering >> about the actual reason to do so, as per one of the famous >> Architectural Principles of the Internet documented in RFC 1958: >> >> 3.2 If there are several ways of doing the same thing, choose one. >> If a previous design, in the Internet context or elsewhere, has >> successfully solved the same problem, choose the same solution unless >> there is a good technical reason not to. Duplication of the same >> protocol functionality should be avoided as far as possible, without >> of course using this argument to reject improvements. >> >> Would you mind enlightening us? >> >> --julien >> >> jouni korhonen wrote: >>> >>> 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 >>> >>> _______________________________________________ >>> MEXT mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/mext >> _______________________________________________ >> MEXT mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/mext