Re: [manet] [EXT] Re: Proposed text for Errata 6472 (and friends)
"Sipos, Brian J." <Brian.Sipos@jhuapl.edu> Mon, 21 March 2022 15:17 UTC
Return-Path: <Brian.Sipos@jhuapl.edu>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0403A0C00 for <manet@ietfa.amsl.com>; Mon, 21 Mar 2022 08:17:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jhuapl.edu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9BaacT4hyfQ for <manet@ietfa.amsl.com>; Mon, 21 Mar 2022 08:17:26 -0700 (PDT)
Received: from aplegw02.jhuapl.edu (aplegw02.jhuapl.edu [128.244.251.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6CE3A08AE for <manet@ietf.org>; Mon, 21 Mar 2022 08:17:25 -0700 (PDT)
Received: from pps.filterd (aplegw02.jhuapl.edu [127.0.0.1]) by aplegw02.jhuapl.edu (8.16.0.43/8.16.0.43) with SMTP id 22LFCoDn194679; Mon, 21 Mar 2022 11:17:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhuapl.edu; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=JHUAPLDec2018; bh=AsA/e5797eynPKXIlsjw0fALcOWO9BNaZmSRDJ3e59c=; b=As+HOCtaavvK2A80QZGMa7U/JQ5POIlCslMtFp04hkjJaDpmpNAB/nOBYOtJVyPaGh9X 1POtAYb0pmDwmRjfVEHClgbggWrRUBe9GvZ578oCjFgvVo5Lyv5dBBINsXmTOjM5Bv6q OFZhNd6PvXhGjC5wDpLbCL5TeYh9r8JhzJkEOCd2OqOxd1idm+STKLilFhl88h39z/et Zqv7Q2/2fzGPi4MlbWALQGX+pUESnwiNoLIw8Lx17rxrCyirwB3+vsLKam/8zjP1y2QX MC7i/I5rCm4Ay2ZvrUif43Yvmvht5Vvhcr1x0E7bHOSuC6fRJgtWDjRr5zIOGbxXbfjx ww==
Received: from aplex26.dom1.jhuapl.edu (aplex26.dom1.jhuapl.edu [10.114.162.11]) by aplegw02.jhuapl.edu with ESMTP id 3ewbd11bfn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Mar 2022 11:17:23 -0400
Received: from APLEX21.dom1.jhuapl.edu (10.114.162.6) by APLEX26.dom1.jhuapl.edu (10.114.162.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.922.20; Mon, 21 Mar 2022 11:17:23 -0400
Received: from APLEX21.dom1.jhuapl.edu ([fe80::3c73:f90:20fa:eda1]) by APLEX21.dom1.jhuapl.edu ([fe80::3c73:f90:20fa:eda1%5]) with mapi id 15.02.0922.020; Mon, 21 Mar 2022 11:17:23 -0400
From: "Sipos, Brian J." <Brian.Sipos@jhuapl.edu>
To: Don Fedyk <dfedyk@labn.net>, Henning Rogge <hrogge@gmail.com>
CC: "manet@ietf.org" <manet@ietf.org>
Thread-Topic: [manet] [EXT] Re: Proposed text for Errata 6472 (and friends)
Thread-Index: AQHYPRdri6oY1fu/t0elugRIiEnnkazJ08Ig
Date: Mon, 21 Mar 2022 15:17:23 +0000
Message-ID: <f24fbf43ce914f5db12f7965fb719af6@jhuapl.edu>
References: <38A5475DE83986499AEACD2CFAFC3F98020B1B9639@tss-server1.home.tropicalstormsoftware.com> <7a3901baf5da4bbeb23adee80a5be596@jhuapl.edu> <CAGnRvurGXxcmbX_s5btwvvTvXnta50Zj=dzOBnM1TkuEW4RT8A@mail.gmail.com> <38A5475DE83986499AEACD2CFAFC3F98020B1BB18D@tss-server1.home.tropicalstormsoftware.com> <4eaa1ca62ad44a2b96fa4b2e538b072f@jhuapl.edu> <CAGnRvuq6oShMivvq85AP=PDe-kwsdLkfD+fY5dzA9-i+Az1EeA@mail.gmail.com> <2409ea9ac7f3475b89c990d6dbce3b91@jhuapl.edu> <MN2PR14MB40306E3790FFE602DE72C3F5BB169@MN2PR14MB4030.namprd14.prod.outlook.com>
In-Reply-To: <MN2PR14MB40306E3790FFE602DE72C3F5BB169@MN2PR14MB4030.namprd14.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.162.27]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="----=_NextPart_000_0120_01D83D15.3BD286D0"
MIME-Version: 1.0
X-CrossPremisesHeadersFilteredBySendConnector: APLEX26.dom1.jhuapl.edu
X-OrganizationHeadersPreserved: APLEX26.dom1.jhuapl.edu
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.850 definitions=2022-03-21_06:2022-03-18, 2022-03-21 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/5ocHYfNlVdk_vKSQhYDi8wU6qok>
Subject: Re: [manet] [EXT] Re: Proposed text for Errata 6472 (and friends)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 15:17:32 -0000
Don, That text seems to cover all of the points that I raised. - Brian S. -----Original Message----- From: Don Fedyk <dfedyk@labn.net> Sent: Monday, March 21, 2022 7:33 AM To: Sipos, Brian J. <Brian.Sipos@jhuapl.edu>; Henning Rogge <hrogge@gmail.com> Cc: manet@ietf.org Subject: RE: [manet] [EXT] Re: Proposed text for Errata 6472 (and friends) APL external email warning: Verify sender dfedyk@labn.net before clicking links or attachments Hi Ronald and I had discussed this Errata being stuck. After reading the threads and the RFC8175 I suggest the following for the Errata. OLD: A Peer Offer Signal MUST be encoded within a UDP packet. The IP source and destination fields in the packet MUST be set by swapping the values received in the Peer Discovery Signal. The Peer Offer Signal completes the discovery process; see Section 7.1. PROPOSED: A Peer Offer Signal MUST be encoded within a UDP packet. The IP source and destination fields (addresses and ports) in the packet MUST be set by swapping the values received in the Peer Discovery Signal, with the exception that the new source address on the Offer Signal, which was the well-known destination address, becomes a local IP from the DLEP modem. The source port remains the well-known port from the Peer Discovery Signal. The Peer Offer signal contains zero or more connection points as described in 13.2 and 13.3 completes the discovery process; see Section 7.1 Comments? Hopefully, this address all the points brought up. Thanks Don Background (all in 7.1): There are three ways to determine addresses for the TCP session: - Using addresses defined in configuration - Using an address and port provided in a connection point during discovery. - Using the source address and well-known port of the Offer Signal. -----Original Message----- From: manet <manet-bounces@ietf.org> On Behalf Of Sipos, Brian J. Sent: Monday, November 22, 2021 12:38 PM To: Henning Rogge <hrogge@gmail.com> Cc: manet@ietf.org Subject: Re: [manet] [EXT] Re: Proposed text for Errata 6472 (and friends) Yes, but as it stands now neither port is currently required to have any specific value for the Peer Offer signal when a Connection Point item is present. Below is a text diagram to show the sequence, where RDO-IP and RTR-IP are the unicast addresses and DLEP-MCAST is the multicast address. The router is not required to use any specific UDP or TCP source port, so it will be assigned some ephemeral (EPH#) port by the IP stack. The Peer Offer then will respond back to the router's address+port but its source is left undefined by the current wording. There's no real harm here; it just makes things more challenging for analysis and things like firewalls. I don't see any particular reason why the Peer Offer source port should not be specified, especially because my suspicion is that implementations are already following the send-from-listening-port-number pattern if they're sending datagrams with the same socket used to listen for multicast, and because the source port is specified for when Connection Point is not used. Radio Router UDP Exchange DLEP-MCAST:854 <- RTR-IP:EPH1 RDO-IP:??? -> RTR-IP:EPH1 TCP Connection RDO-IP:854 <- RTR-IP:EPH2 -----Original Message----- From: Henning Rogge <hrogge@gmail.com> Sent: Saturday, November 20, 2021 1:03 AM To: Sipos, Brian J. <Brian.Sipos@jhuapl.edu> Cc: Rick Taylor <rick@tropicalstormsoftware.com>; manet@ietf.org Subject: [EXT] Re: [manet] Proposed text for Errata 6472 (and friends) APL external email warning: Verify sender hrogge@gmail.com before clicking links or attachments Wouldn't it be easy to configure the firewall to Radio (router is the other way around): ALLOW: outgoing UDP with src-port 854 ALLOW: incoming UDP with dst-port 854 Henning On Fri, Nov 19, 2021 at 9:20 PM Sipos, Brian J. <Brian.Sipos@jhuapl.edu> wrote: > > Rick, > All of these details make sense and I don't disagree with any of the discussion. I believe it would just be helpful for the spec to fully define the Peer Offer source UDP port so that, for example, a Router can configure a firewall and know that things are going to work. If I know that a modem (of some type) is "operating on" UDP and TCP port X, then I can configure my router firewall to allow inbound UDP source port X and not run into a situation where the modem sends UDP from some other port that my firewall will drop. > > I agree that the UDP source port could be anything and the router application doesn't care; and I expect that current implementations are already responding with a well-defined source port as your notional example shows. It’s the middle-boxes between modem and router application that could be an issue if the port is left unconstrained (when a Connection Point is present within). This is especially true because the Peer Discovery uses a multicast address, so there is no "UDP conversation" to follow from a middle-box's perspective. > > -----Original Message----- > From: Rick Taylor <rick@tropicalstormsoftware.com> > Sent: Friday, November 19, 2021 4:39 AM > To: Henning Rogge <hrogge@gmail.com>; Sipos, Brian J. > <Brian.Sipos@jhuapl.edu> > Cc: manet@ietf.org > Subject: [EXT] RE: [manet] Proposed text for Errata 6472 (and friends) > > APL external email warning: Verify sender > rick@tropicalstormsoftware.com before clicking links or attachments > > Hi Both, > > IPv4/6 Connection Point data items contain a port number, so there is > no confusion about which port to use to establish the TCP session when > the Data Item is included in the response. The Source IP/port in the > response is irrelevant - it just needs to be 'valid' (i.e. not > multicast, etc). The source port can be ephemeral, as nothing is > listening for anything further on that port. > > When Connection Point data items are missing, set the Source IP/Port > of the Peer Offer response packet to the TCP IP/port combo that is > listening for the TCP session connect(). In most cases, that will be > the same IP address and port (854) as the Discovery UDP is using, so > there is little to do programmatically, it's only difficult when the ports are different. > > In either case, always set the destination IP/port to the Source combo > of the original Discovery signal. > > When writing this using the BSD sockets API, a lot of this ephemeral > port detail is skipped thanks to the API. As a modem: > > 1. Create a S1 = socket(UDP) > 2. bind(S1) to DLEP interface, port 854. > 3. Join the multicast group > 4. recvfrom(S1, Peer Discovery) > 5a. If we use Connection Point Data Items, or use the same address and port > 854 for the TCP session: sendto(S1, Peer offer) to source sockaddr of the > received packet. > 5b. Else: create a new S2 = socket(UDP) and bind(S2) to DLEP > interface, UDP port = custom TCP port, then sendto(S2, Peer offer) to > source sockaddr of the received packet. > > Does that help? > > Cheers, > > Rick > > > -----Original Message----- > > From: Henning Rogge [mailto:hrogge@gmail.com] > > Sent: 19 November 2021 08:44 > > To: Sipos, Brian J. > > Cc: Rick Taylor; manet@ietf.org > > Subject: Re: [manet] Proposed text for Errata 6472 (and friends) > > > > You cannot do the receiver for the UDP discovery packets on an > > ephemeral port anyways... wouldn't it be the usual thing just use > > the same socket for sending the unicast reply? > > > > Henning Rogge > > > > On Tue, Nov 16, 2021 at 11:26 PM Sipos, Brian J. > > <Brian.Sipos@jhuapl.edu> > > wrote: > > > > > > Rick, > > > For the first condition (connection point is present) there is > > > still a lack of preference for UDP port number, which leaves things open. > > > Can the source > > UDP > > > port in that case be required (even a SHOULD would help) to be the > > > same > > port > > > number listened-for by the modem (i.e. the destination the port > > > number of > > the > > > Peer Discovery Signal)? > > > > > > In a typical case, I expect the modem would be listening on > > > standard UDP > > port > > > 854 so the Peer Offer would have a source port of 854. This makes > > > things easier on traffic monitors so that it's not a UDP datagram > > > from ephemeral-to-ephemeral port. It could also simplify > > > implementation > > because the > > > listening bound socket would also be usable for sending the response. > > > > > > Thanks, > > > Brian S. > > > > > > -----Original Message----- > > > From: manet <manet-bounces@ietf.org> On Behalf Of Rick Taylor > > > Sent: Friday, November 12, 2021 11:36 AM > > > To: manet@ietf.org > > > Subject: [EXT] [manet] Proposed text for Errata 6472 (and friends) > > > > > > APL external email warning: Verify sender manet-bounces@ietf.org > > > before clicking links or attachments > > > > > > Hi All, > > > > > > Here is my proposed text for the raised Errata. Please review and > > comment, as > > > there are particular combinations of if/MUST/else that can be confusing. > > > > > > ------ > > > Section 12.4, para 2. Replace with: > > > > > > A Peer Offer Signal MUST be encoded within a UDP packet. The > > > destination > > IP > > > address and UDP port of the packet MUST be the source IP address > > > and > > UDP port > > > of the received Peer Discovery Signal packet. If the modem > > > includes > > > IPv4 or > > > IPv6 Connection Point Data Items in the Peer Offer Signal then the > > > source IP address and UDP port of the packet may be any valid > > > local UDP > > address/port > > > combination. If the Peer Offer Signal does not include IPv4 or > > > IPv6 Connection Point Data Items, then the source IP address and > > > UDP port of > > the > > > packet MUST be set to the unicast IP address and TCP port the > > > router MUST > > use > > > when connecting the DLEP TCP session, as defined in Section 7.1. > > > The Peer Offer Signal completes the discovery process. > > > ----- > > > > > > Cheers, > > > > > > Rick > > > > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www.ietf.org/mailman/listinfo/manet > > > _______________________________________________ > > > manet mailing list > > > manet@ietf.org > > > https://www.ietf.org/mailman/listinfo/manet
- [manet] Proposed text for Errata 6472 (and friend… Rick Taylor
- Re: [manet] Proposed text for Errata 6472 (and fr… Sipos, Brian J.
- Re: [manet] Proposed text for Errata 6472 (and fr… Henning Rogge
- Re: [manet] Proposed text for Errata 6472 (and fr… Rick Taylor
- Re: [manet] Proposed text for Errata 6472 (and fr… Henning Rogge
- Re: [manet] Proposed text for Errata 6472 (and fr… Sipos, Brian J.
- Re: [manet] Proposed text for Errata 6472 (and fr… Henning Rogge
- Re: [manet] [EXT] Re: Proposed text for Errata 64… Sipos, Brian J.
- Re: [manet] [EXT] Re: Proposed text for Errata 64… Don Fedyk
- Re: [manet] [EXT] Re: Proposed text for Errata 64… Sipos, Brian J.