Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec

[Jouni <[e-mail]>]

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" <[e-mail]>
>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>> 
>>>>> _______________________________________________
>>>>> MEXT mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>> _______________________________________________
>>>> MEXT mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mext
>