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

On Nov 13, 2013, at 11:13 AM, Teco Boot <teco@inf-net.nl> wrote:

> 
> Op 13 nov. 2013, om 16:55 heeft Stan Ratliff (sratliff) <sratliff@cisco.com> het volgende geschreven:
> 
>> 
>> On Nov 13, 2013, at 10:42 AM, Teco Boot <teco@inf-net.nl> wrote:
>> 
>>> 
>>> Op 13 nov. 2013, om 16:21 heeft Taylor, Rick <Rick.Taylor@cassidian.com> het volgende geschreven:
>>> 
>>>> Having recently spoken to a radio vendor, they too run a serious amount of services on their hardware, including a full linux routing stack, so being a server is no issue.
>>>> 
>>>> However, I still think the router is the correct device to be the server simply from the 1 to many relationship between router and modems.  One router has multiple simultaneous sessions with modems.  Modems have only one conversation with a router at once, this seems to match the router being the server and the modem calling connect().
>>> 
>>> Maybe it is you as vendor of this single router.
>>> I’m the network designer, that builds networks that are adaptive. I hate limitations build in into protocols disallowing services of my modems.
>> 
>> I don't see this discussion as building in limitations or disallowing services…. and if so, then I would argue that putting the TCP server code into the modem would then build limitations (and/or disallow services) *from the router*. 
>> 
>> So what, exactly, are the use cases and technical reasons for hosting the TCP server at the modem? 
> 
> Two items here:
> a) 1 to many relationship between router and modems
> b) TCP server at the modem
> 
> On a) I reject this limitation

I don't want the limitation either. Putting the TCP server at the router doesn't cause that limitation. 

> 
> On b) I don’t prefer a more complex protocol for making life more easy for modem vendors.
> 
> The proposal from Rich is a way out on b.

Subjective. I don't see Rick's proposal as complex. I see it as making sense. Also, having the "world's greatest IETF specification" is meaningless if no radio vendors actually implement it. I'd prefer tradeoffs that actually entice vendors to implement. 

Stan

> 
> Teco
> 
> 
>> Stan
>> 
>> 
>>> 
>>> Another reason: current proprietary protocols don’t have this limitation. So the restriction actually limits adaption of DLEP.
>> 
>> I don't understand this either. Any protocol that is TCP based has to have a TCP server and a TCP client. Do you mean that the current proprietary protocols are not TCP based? That would imply to me that perhaps the DT decision to go to TCP in the first place was ill-conceived (after all, there was a bit of working group angst when that was announced). 
>> 
>> Stan
>> 
>> 
>>> 
>>> Teco
>>> 
>>> 
>>>> 
>>>> Rick Taylor
>>>> 
>>>>> -----Original Message-----
>>>>> From: manet-dlep-rg-bounces@ietf.org [mailto:manet-dlep-rg-
>>>>> bounces@ietf.org] On Behalf Of Henning Rogge
>>>>> Sent: 13 November 2013 13:07
>>>>> To: Stan Ratliff (sratliff)
>>>>> Cc: DLEP Research Group (manet-dlep-rg@ietf.org); Teco Boot
>>>>> Subject: Re: [manet-dlep-rg] DLEP session establishment
>>>>> 
>>>>> I talked with a co-worker from our SDR department.
>>>>> 
>>>>> He said that most SDRs he works with have mid- to high-end ARM/MIPS
>>>>> CPUs for handhelds and even more powerful ones for vehicle based SDRs.
>>>>> 
>>>>> These devices already have the necessary libraries on board to open
>>>>> tcp server sockets for other purposes, software complexity for opening
>>>>> the socket should be no real issue.
>>>>> 
>>>>> The other target platform I have in mind for DLEP are cheap embedded
>>>>> routers that are converted into DLEP-capable radios with a special
>>>>> firmware. They also have a full IP stack already present, a TCP server
>>>>> socket is a non-issue with them either.
>>>>> 
>>>>> Henning Rogge
>>>>> 
>>>>> On Tue, Nov 12, 2013 at 8:59 PM, Stan Ratliff (sratliff)
>>>>> <sratliff@cisco.com> wrote:
>>>>>> Teco,
>>>>>> 
>>>>>> On Nov 12, 2013, at 2:05 PM, Teco Boot <teco@inf-net.nl> wrote:
>>>>>> 
>>>>>>> Access list on modem is needed if not on trusted network.
>>>>>>> (all networks are less trusted these days...)
>>>>>>> 
>>>>>>> Stan: you have received from multiple sources that modem may have more
>>>>> CPU power and memory than the router. Elect TCP server based on clock
>>>>> speed & memory footprint? As a router vendor, why not taking the easy
>>>>> part?
>>>>>> 
>>>>>> One additional thought on this topic. In an earlier email on this same
>>>>> thread, you said (in part):
>>>>>> "...Let's keep the modem a somewhat dummy device."
>>>>>> 
>>>>>> I 100% agree with that approach. It's part of what drives me to put
>>>>> "harder" code (like being a TCP server) into the router, not the modem.
>>>>>> 
>>>>>> Stan
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> Teco
>>>>>>> 
>>>>>>> Op 12 nov. 2013, om 19:54 heeft Stan Ratliff (sratliff)
>>>>> <sratliff@cisco.com> het volgende geschreven:
>>>>>>> 
>>>>>>>> That's fair. Also not what I was driving at, so my apologies. It goes
>>>>> back to my contention that TCP server code is "arguably more complex" than
>>>>> client code, and therefore, we should endeavor to put the TCP client code
>>>>> in the modem.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Stan
>>>>>>>> 
>>>>>>>> On Nov 12, 2013, at 1:47 PM, Henning Rogge <hrogge@googlemail.com>
>>>>> wrote:
>>>>>>>> 
>>>>>>>>> I don't think defending against spoofed IP packets, Syn-Floods or
>>>>> just
>>>>>>>>> DDOS should be part of DLEP.
>>>>>>>>> 
>>>>>>>>> We have other layers for this.
>>>>>>>>> 
>>>>>>>>> Henning Rogge
>>>>>>>>> 
>>>>>>>>> On Tue, Nov 12, 2013 at 7:46 PM, Stan Ratliff (sratliff)
>>>>>>>>> <sratliff@cisco.com> wrote:
>>>>>>>>>> Fair point. Use of TLS would also help. But I don't think any of
>>>>> that defends against a SYN flood....  that requires things like a tight rein
>>>>> on listen depth, etc.
>>>>>>>>>> 
>>>>>>>>>> Regards,
>>>>>>>>>> Stan
>>>>>>>>>> 
>>>>>>>>>> On Nov 12, 2013, at 1:42 PM, Henning Rogge <hrogge@googlemail.com>
>>>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> If you consider multi-hop connectivity, maybe using a VPN-Box might
>>>>> be
>>>>>>>>>>> a good idea... let the radio believe its single hop and outsource
>>>>> the
>>>>>>>>>>> security. ;)
>>>>>>>>>>> 
>>>>>>>>>>> Henning Rogge
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Nov 12, 2013 at 7:40 PM, Stan Ratliff (sratliff)
>>>>>>>>>>> <sratliff@cisco.com> wrote:
>>>>>>>>>>>> Henning,
>>>>>>>>>>>> 
>>>>>>>>>>>> I agree, I don't think most networks forward IPv6 link-locals.
>>>>> But, once you consider the problem of allowing multi-hop connectivity,
>>>>> you've got the issue of defending against SYN attacks, etc. IMO, that is
>>>>> yet another reason for putting the TCP server functionality into the
>>>>> *router*, not the modem. The burden on the poor, supposedly resource-
>>>>> constrained modem just gets bigger, and bigger, and bigger...
>>>>>>>>>>>> 
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Stan
>>>>>>>>>>>> 
>>>>>>>>>>>> On Nov 12, 2013, at 1:36 PM, Henning Rogge <hrogge@googlemail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> I think most operation systems do not forward linklocal IPv6
>>>>> addresses...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Henning Rogge
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Tue, Nov 12, 2013 at 7:30 PM, Teco Boot <teco@inf-net.nl>
>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Op 12 nov. 2013, om 19:05 heeft Henning Rogge
>>>>> <hrogge@googlemail.com> het volgende geschreven:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Easiest way to protect yourself against most "long range"
>>>>> attacks is
>>>>>>>>>>>>>>> to bind the TCP socket to an IPv6 linklocal address.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> There is traffic with IPv6 link local address on the Internet.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Sent packets with IPv6 link local address should have
>>>>> hopcount=1. Doesn't completely take away the problem. TTL=255 filter on
>>>>> incoming traffic is stronger (GTSM, RFC 5082).
>>>>>>>>>>>>>> Use GTSM filter and IPv6 link-local addresses by default?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Rick and I came up with the idea DLEP can be used between peers
>>>>> multiple hops away. Modem may have an option allowing it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Teco
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Henning Rogge
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Tue, Nov 12, 2013 at 7:04 PM, Teco Boot <teco@inf-net.nl>
>>>>> wrote:
>>>>>>>>>>>>>>>> TCP 4-tupple is not enough to discard some form of blind TCP
>>>>> connect. There must be some sanity check.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Radio must protect itself against syn attack (no data, locked
>>>>> port).
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Teco
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Op 12 nov. 2013, om 17:21 heeft Taylor, Rick
>>>>> <Rick.Taylor@cassidian.com> het volgende geschreven:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>> manet-dlep-rg mailing list
>>>>>>>>>>>>>>>>> manet-dlep-rg@ietf.org
>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> manet-dlep-rg mailing list
>>>>>>>>>>>>>>>> manet-dlep-rg@ietf.org
>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> We began as wanderers, and we are wanderers still. We have
>>>>> lingered
>>>>>>>>>>>>>>> long enough on the shores of the cosmic ocean. We are ready at
>>>>> last to
>>>>>>>>>>>>>>> set sail for the stars - Carl Sagan
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> --
>>>>>>>>>>>>> We began as wanderers, and we are wanderers still. We have
>>>>> lingered
>>>>>>>>>>>>> long enough on the shores of the cosmic ocean. We are ready at
>>>>> last to
>>>>>>>>>>>>> set sail for the stars - Carl Sagan
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> --
>>>>>>>>>>> We began as wanderers, and we are wanderers still. We have lingered
>>>>>>>>>>> long enough on the shores of the cosmic ocean. We are ready at last
>>>>> to
>>>>>>>>>>> set sail for the stars - Carl Sagan
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> manet-dlep-rg mailing list
>>>>>>>>>>> manet-dlep-rg@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> We began as wanderers, and we are wanderers still. We have lingered
>>>>>>>>> long enough on the shores of the cosmic ocean. We are ready at last
>>>>> to
>>>>>>>>> set sail for the stars - Carl Sagan
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> manet-dlep-rg mailing list
>>>>>> manet-dlep-rg@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/manet-dlep-rg
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> We began as wanderers, and we are wanderers still. We have lingered
>>>>> long enough on the shores of the cosmic ocean. We are ready at last to
>>>>> set sail for the stars - Carl Sagan
>>>>> _______________________________________________
>>>>> 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
>>> 
>> 
> 
> _______________________________________________
> manet-dlep-rg mailing list
> manet-dlep-rg@ietf.org
> https://www.ietf.org/mailman/listinfo/manet-dlep-rg