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

["Laganier, Julien" <[e-mail]>]

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. 

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...

--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
> >