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

[Jouni <[e-mail]>]

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