Re: [manet] Proposed text for Errata 6472 (and friends)

["Sipos, Brian J." <[e-mail]>]

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 <[e-mail]>
Sent: Friday, November 19, 2021 4:39 AM
To: Henning Rogge <[e-mail]>; Sipos, Brian J. <[e-mail]>
Cc: [e-mail]
Subject: [EXT] RE: [manet] Proposed text for Errata 6472 (and friends)

APL external email warning: Verify sender [e-mail] 
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:[e-mail]]
> Sent: 19 November 2021 08:44
> To: Sipos, Brian J.
> Cc: Rick Taylor; [e-mail]
> 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.
> <[e-mail]>
> 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 <[e-mail]> On Behalf Of Rick Taylor
> > Sent: Friday, November 12, 2021 11:36 AM
> > To: [e-mail]
> > Subject: [EXT] [manet] Proposed text for Errata 6472 (and friends)
> >
> > APL external email warning: Verify sender [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet
> > _______________________________________________
> > manet mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/manet