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]> |
Hmm.. we do handle SPIs differently and our "ESP" can be absent even if UDP encap is used. Would that be an issue regarding the reuse of existing formats? - Jouni On Jan 29, 2011, at 12:29 AM, Laganier, Julien wrote: > Either. > > IMHO both would be cleaner that the current approach. I understand the latter might also have some caveat but maybe they can be dealt with in an elegant manner, without introducing too much complexity, e.g., see Arnaud's m6t (http://tools.ietf.org/html/draft-ebalard-mext-m6t-02.txt) > > --julien > > Jouni wrote: >> >> 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 >