Re: [manet-dlep-rg] DLEP session establishment

I seem to remember SCTP (which I hold in high regard) uses a cookie for its 4-way handshake on the grounds that it stops some types of spoofing attacks.

I'll re-read their rationale doc if I can find it.  I was just trying to cover some security considerations here, but it might be misplaced.

I just wonder whether replying to a broadcast with a IP address by blindly connecting to it without some way of checking what your connecting to is what you expect to be there is 'unsafe' - but you do make a good point about the TCP 4-tuple...

Rick Taylor

> -----Original Message-----
> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
> Sent: 12 November 2013 16:04
> To: Taylor, Rick
> Cc: DLEP Research Group (manet-dlep-rg@ietf.org)
> Subject: Re: [manet-dlep-rg] DLEP session establishment
>
> Rick,
>
> On Nov 12, 2013, at 10:45 AM, "Taylor, Rick" <Rick.Taylor@cassidian.com>
> wrote:
>
> > Hmmm... good point about complexity in the radio Stan.
> >
> > I'd be okay with flipping the whole discovery process so the router
> advertises and the radio connects.  Making the router maintain the extra
> timer for strobing is probably more sensible.  Obviously some
> recommendation for timing of the strobes is needed.
> >
> > The handshake still stays 3-way and that covers most of my concerns.
> >
> > Any comment on a cookie in the offer?
>
> What is the cookie used for? I was thinking the TCP 4-tuple (Source
> IP/Source Port/Destination IP/Destination Port) is sufficient for any
> correlation.
>
> Regards,
> Stan
>
> >
> > I have double checked with the 04 draft, and you have covered the
> broadcast or configured unicast UDP address in the text, so I'm happy.
> >
> > Rick Taylor
> >
> >> -----Original Message-----
> >> From: Stan Ratliff (sratliff) [mailto:sratliff@cisco.com]
> >> Sent: 12 November 2013 15:17
> >> To: Taylor, Rick
> >> Cc: DLEP Research Group (manet-dlep-rg@ietf.org)
> >> Subject: Re: [manet-dlep-rg] DLEP session establishment
> >>
> >> OK, looks like my opinion is "in the rough" on this one...
> >>
> >> But I'm still concerned about putting the TCP "server" code into the
> >> (probably more) constrained modem device. So, what if we make the
> *router*
> >> issue the Peer Discovery (call it a Peer Advertisement) to an MCAST
> >> address/well-known port? That Peer Discovery/Peer Advertisement would
> >> contain the unicast IP address/port for the TCP listener. The modem
> would
> >> respond with the TCP SYN...
> >>
> >> The router would continue to periodically "strobe" the Peer
> Discovery/Peer
> >> Advertisement ad-nauseum (as much as I hate that approach).
> >>
> >> I'm really concerned about modem-side complexity, based on discussions
> I
> >> had a couple of years ago with some radio vendors who were looking at
> >> implementing.
> >>
> >> Regards,
> >> Stan
> >>
> >> On Nov 12, 2013, at 7:47 AM, "Taylor, Rick" <Rick.Taylor@cassidian.com>
> >> wrote:
> >>
> >>> Sorry for the delay, I was out of office yesterday.
> >>>
> >>> My thoughts:
> >>>
> >>>   Router                                        Modem
> >>>   ===================================================
> >>>
> >>> 1)                                  TCP socket listen()
> >>>
> >>> 2)  <--------------------------- Peer Discovery Message
> >>>                             UDP unicast or broadcast?
> >>>                                      + Session Cookie
> >>>                                    + TCP address/port
> >>>          + Alternate reliable protocol endpoint infos
> >>>
> >>> 3)  TCP connect()
> >>>
> >>> 4)  Initialize (was Peer Offer) ---------------------->
> >>>   + Session Cookie
> >>>
> >>> 5)  <----------------------------------- Initialize ACK
> >>>                                      + Session Cookie
> >>>                               + Supported metric TLVs
> >>>
> >>>
> >>> My reasoning, often agreeing with others:
> >>>
> >>> The Modem 'advertises' its DLEP support, and therefore should
> >>> be the one that listens for the TCP connect.
> >>>
> >>> A cookie passed between the UDP discovery message and the TCP
> >>> connection adds a little security (is this the modem I think I am
> >>> connecting to?)  This could be extended to a full signature TLV
> >>> in a later RFC.
> >>>
> >>> The Peer Discovery message could carry additional reliable
> >>> protocol endpoint information for non-TCP transports.
> >>>
> >>> The Initialize ACK is the correct place to put the 'default'
> >>> metric TLVs, and is sent by the modem.
> >>>
> >>> A 3-way handshake seems safer to me.
> >>>
> >>> I have a question over whether the Peer Discovery message should
> >>> be unicast to a configured destination, or broadcast to all
> >>> connected peers on a TBD port.  I prefer broadcast as it is more
> >>> ZeroConf, but I can see use-cases for unicast to a configured
> >>> destination for more complex topologies.
> >>>
> >>> Cheers,
> >>>
> >>> Rick Taylor
> >>>
> >>>> -----Original Message-----
> >>>> From: manet-dlep-rg-bounces@ietf.org [mailto:manet-dlep-rg-
> >>>> bounces@ietf.org] On Behalf Of Teco Boot
> >>>> Sent: 11 November 2013 16:29
> >>>> To: Stan Ratliff
> >>>> Cc: DLEP Research Group (manet-dlep-rg@ietf.org)
> >>>> Subject: [manet-dlep-rg] DLEP session establishment
> >>>>
> >>>>
> >>>> Op 11 nov. 2013, om 01:55 heeft Stan Ratliff (sratliff)
> >>>> <sratliff@cisco.com> het volgende geschreven:
> >>>>
> >>>>> Also, as to the Discovery: Here's what I'm writing up as we speak:
> >>>>>
> >>>>>
> >>>>> Router
> >>>> Modem
> >>>>> ========================================
> >>>>>                                   <------------------------ Peer
> >>>> Discovery Message
> >>>>> Peer Offer with           ------------------------->
> >>>>> unicast IP addr/
> >>>>> port for TCP connect
> >>>>
> >>>> So this is multicast reply, telling modem to connect?
> >>>> Why not TCP connect from router to modem? Makes more sense to me, the
> >>>> modem is the peer offering a service.
> >>>> Maybe add a TcpPort TLV in the Peer Discovery, this allows other than
> >> IANA
> >>>> assigned ports.
> >>>>
> >>>>
> >>>>>
> >>>>> *Connect on TCP socket. Router has issued TCP "listen",
> >>>>>  modem issues TCP "connect" (e.g. Modem is the TCP "client",
> >>>>>  router is the TCP "server")
> >>>>>
> >>>>> Now, The modem's UDP socket can be closed.
> >>>>
> >>>> Please don't.
> >>>>
> >>>>
> >>>>> Over the TCP
> >>>>> Socket,
> >>>>>                                  <------------------------- Peer
> >>>> Initialization containing
> >>>>>
> >>>> TLVs/default values for ALL
> >>>>>
> >>>> supported metric values - all
> >>>>>
> >>>> meaning the MANDATORY ones,
> >>>>>
> >>>> plus any optional metrics (right now,
> >>>>>
> >>>> just Resources) that are supported.
> >>>>
> >>>> Yes, here the full set TLV exchange takes place. This should not be
> in
> >> the
> >>>> Peer Discovery. That's why I suggested to put this in the Peer Offer.
> >>>>
> >>>>
> >>>>>
> >>>>> Peer Initialization ACK ---------------------->
> >>>>> MAY contain optional
> >>>>> Layer 3 (address) TLVs
> >>>>
> >>>> I'm fine with three way handshake, not with this two way. Or use TCP
> >>>> disconnect when modem modem is not willing to accept first message
> from
> >>>> router.
> >>>>
> >>>> Teco
> >>>>
> >>>>>
> >>>>> .... And, everything from there is basically the same as before.
> >>>>
> >>>> _______________________________________________
> >>>> manet-dlep-rg mailing list
> >>>> manet-dlep-rg@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
> >>> The information contained within this e-mail and any files attached to
> >> this e-mail is private and in addition may include commercially
> sensitive
> >> information. The contents of this e-mail are for the intended recipient
> >> only and therefore if you wish to disclose the information contained
> >> within this e-mail or attached files, please contact the sender prior
> to
> >> any such disclosure. If you are not the intended recipient, any
> >> disclosure, copying or distribution is prohibited. Please also contact
> the
> >> sender and inform them of the error and delete the e-mail, including
> any
> >> attached files from your system. Cassidian Limited, Registered Office :
> >> Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company
> No:
> >> 04191036 http://www.cassidian.com
> >
> > The information contained within this e-mail and any files attached to
> this e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient
> only and therefore if you wish to disclose the information contained
> within this e-mail or attached files, please contact the sender prior to
> any such disclosure. If you are not the intended recipient, any
> disclosure, copying or distribution is prohibited. Please also contact the
> sender and inform them of the error and delete the e-mail, including any
> attached files from your system. Cassidian Limited, Registered Office :
> Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No:
> 04191036 http://www.cassidian.com

The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com