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

[jouni korhonen <[e-mail]>]

Hi Julien,


On Jan 29, 2011, at 1:10 AM, Laganier, Julien wrote:

> None of these two points explains to me why you have to duplicate ESP functionality:
> 
> 1) You have chosen to handle SPI differently, but I don't know why. 

That was a design decision for easily to detect the type of the UDP payload. In some other cases folks have used algorithms, hash functions and such to encode more information into the SPI but we thought that would an too much. Therefore, we just dedicated few bits of the SPI for additional information.

> 2) As to ESP being absent, if the goal is to not protect some of the user-plane traffic, you can use ESP-NULL, or just the UDP encap...

Well, yes-ish. However, if I decided to send a packet without being protected, then after dispatching the packet (that is based on our SPI with type information) why would I need to do any further processing on it? If you got ESP-NULL, you still need to do additional processing like integrity check (if I were to follow ESP rules). I admit it might be "minor" but still.

So, I'll just ask once more. If I were to use ESP format laid out in other RFC and reference to them to make sure the format processing goes right, is it OK for me then to go against all MUSTs and SHALLs for the rest of the ESP rules, for example when it comes to handling of ESP-NULL?



- JOuni

> 
> --julien
> 
> None of the above explains why you need to 
> 
> Jouni wrote:
>> 
>> 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
>>> 
>