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

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