Subject: [manet] DLEP-23 addition of RFC 5082 requirement

From: "Viberg, Neil" <[email-masked]>
Date: Tue, 19 Jul 2016 21:23:14 +0000

Folks,

I'm confused and I'm hoping someone can help me out.

1.       The update includes a requirement to implement RFC 5082 and then indicates that UDP-based signals shall have a TTL of 1. RFC 5082 never talks about a TTL of 1, it only refers to a TTL of 255. Seems that being compliant with DLEP and RFC 5082 at the same time will be difficult. In addition, the only way to see the TTL from a socket call is to use raw sockets AFAIK. Is that the correct? Is that the intent?

2.       DLEP-23 requires that all messages have a TTL of 255. The problem is that a DLEP message is a logical construction received over a TCP byte stream and the byte stream doesn't inherently have a TTL. How does that work? RFC 5082 seems more logical, all packets received as part of the TCP session must have a TTL of 255. That is clear. How does a programmer, using sockets, determine that each of the TCP packets has a TTL of 255? There doesn't appear to be any sockopts that can set that requirement and I doubt many people are going to write their own TCP stack or mangle an existing one to get that done. Again, how is that supposed to work?

Hopefully I'm missing something because the intent of the requirement is clear and laudable but the practicality of it seems suspect.

Cheers,

Neil

>> Date: Mon, 18 Jul 2016 17:43:31 -0400

>> From: Stan Ratliff <[email-masked]<mailto:[email-masked]>>

>> To: MANET IETF <[email-masked]<mailto:[email-masked]>>

>> Subject: [manet] Fwd:  I-D Action: draft-ietf-manet-dlep-23.txt

>> Message-ID:

>>           <CALtoyo=[email-masked]<mailto:CALtoyo=[email-masked]>>

>> Content-Type: text/plain; charset="utf-8"

>> Hello Working Group,

>> As you can see, there is a DLEP-23 that was posted tonight. This version was prompted by comments received in the AD review. Most of the changes are editorial - the biggest change of the bunch is a requirement to implement

>> RFC5082 (The Generalized TTL Security Mechanism, or GTSM). With GTSM, DLEP now requires all UDP-based signals to be sent with TTL=1. All TCP-based DLEP Messages are sent with TTL=255. The TTL values are checked on receipt, and the packets are >> discarded if the TTLs don't match-up. The use of GTSM is to mandate that DLEP run over 1 physical hop only - it enforces the requirement that we run on a single Layer 2 domain.

>> Regards,

>> Stan

---

From: Rick Taylor <[email-masked]>
Date: Tue, 19 Jul 2016 21:56:16 +0000

> Folks,

Hi Neil,

Comments inline...

>  
> I’m confused and I’m hoping someone can help me out.
>  
> 1.       The update includes a requirement to implement RFC 5082 and
> then indicates that UDP-based signals shall have a TTL of 1. RFC 5082
> never talks about a TTL of 1, it only refers to a TTL of 255. Seems
> that being compliant with DLEP and RFC 5082 at the same time will be
> difficult. In addition, the only way to see the TTL from a socket
> call is to use raw sockets AFAIK. Is that the correct? Is that the
> intent?

That is the intent.  Using UDP TTL of 1 is to prevent multihop
discovery messages from even reaching the modem.  Working it through,
it would be possible for a 'bad' implementation to force discovery
messages to traverse multiple hops, with the receiver seeing a TTL of
1, but that is caught by the TTL 255 requirement on the connection.  

A well-behaved implementation will set a TTL of 1 preventing
unnecessary routing of packets even if using a non-link-local address. 

This is not RFC 5082 behaviour but a mechanism to prevent multi-hop
discovery.

Using TTL 255 for the TCP connection is to detect and guarantee that
the TCP peer is only one hop away, as defined by RFC 5082.

>  
> 2.       DLEP-23 requires that all messages have a TTL of 255. The
> problem is that a DLEP message is a logical construction received
> over a TCP byte stream and the byte stream doesn’t inherently have a
> TTL. How does that work? RFC 5082 seems more logical, all packets
> received as part of the TCP session must have a TTL of 255. That is
> clear. How does a programmer, using sockets, determine that each of
> the TCP packets has a TTL of 255? There doesn’t appear to be any
> sockopts that can set that requirement and I doubt many people are
> going to write their own TCP stack or mangle an existing one to get
> that done. Again, how is that supposed to work?

I know a reasonably modern Linux has a user-mode socket ioctl
(IP_MINTTL - https://lwn.net/Articles/379070/) to restrict the TTL on a
socket, and ioctl(IP_TTL) can be used with UDP to get the datagram TTL.
 Other operating systems may have similar behaviour.

>  
> Hopefully I’m missing something because the intent of the requirement
> is clear and laudable but the practicality of it seems suspect.

The intent is to enforce the single layer-2 connectivity requirement,
preventing: a) The discovery of modems more than 1 hop away, and b)
establishing a TCP connection to a modem more than 1 hop away.

Hope that helps,

Rick

> >> From: Stan Ratliff <[email-masked]>
> >> To: MANET IETF <[email-masked]>
> >>           <CALtoyo=R+71Jak7qKvpTphPyTtP8OkESFxQvmkU+V9W04rimcw@mai
> l.gmail.com>
> >> As you can see, there is a DLEP-23 that was posted tonight. This
> version was prompted by comments received in the AD review. Most of
> the changes are editorial - the biggest change of the bunch is a
> requirement to implement
> >> RFC5082 (The Generalized TTL Security Mechanism, or GTSM). With
> GTSM, DLEP now requires all UDP-based signals to be sent with TTL=1.
> All TCP-based DLEP Messages are sent with TTL=255. The TTL values are
> checked on receipt, and the packets are >> discarded if the TTLs
> don't match-up. The use of GTSM is to mandate that DLEP run over 1
> physical hop only - it enforces the requirement that we run on a
> single Layer 2 domain.
> >> 
> >> Regards,
> >> Stan
>  
>  
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Viberg, Neil" <[email-masked]>
Date: Tue, 19 Jul 2016 23:59:10 +0000

Thanks Rick,

I understood the purpose of the requirements and I have no problem with the intent of it all.

You've cleared up my question on TCP. I was looking at sockopts not ioctls, so, thank you for that information. Your line about "Other operating systems may have similar behaviour" may be a little worrying to those that don't use Linux but presumably they will weigh in if it is an issue.

I understand what you've said about the UDP TTL of 1 and you've indicated how to get that. That's great.

My confusion about UDP TTLs arose because the paragraph:

          To enforce the single Layer 2 domain, implementations MUST support the Generalized TTL Security Mechanism [RFC5082].

makes a blanket statement without constraint to UDP or TCP. I would normally interpret it as applying to all data exchanges since the RFC can apply to both TCP and UDP.

It may clearer if:

   DLEP MUST be implemented on a single Layer 2 domain.  The protocol
   identifies next-hop destinations by using the MAC address for
   delivering data traffic.  No manipulation or substitution is
   performed; the MAC address supplied in all DLEP Messages is used as
   the Destination MAC address for frames emitted by the participating
   router.  MAC addresses MUST be unique within the context of router-
   modem session.

   To enforce the single Layer 2 domain, implementations MUST support
   The Generalized TTL Security Mechanism [RFC5082].

   DLEP specifies UDP multicast for single-hop discovery signaling, and
   TCP for transport of the Messages.  Modems and routers participating
   in DLEP sessions MUST have topologically consistent IP addresses
   assigned.  It is RECOMMENDED that DLEP implementations utilize IPv6
   link-local addresses to reduce the administrative burden of address
   assignment.  Implementations MUST adhere to the procedure documented
   in [RFC5082] for all DLEP Messages (TCP traffic).

   In order to keep the DLEP discovery Signals, which are multicast UDP-
   based, limited to the same Layer 2 domain, implementations MUST set
   the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on
   receipt of DLEP Signals.  Any signal received with a TTL not equal to
   1 MUST be discarded.

was replaced with something like:
 
   DLEP MUST be implemented on a single Layer 2 domain.  The protocol
   identifies next-hop destinations by using the MAC address for
   delivering data traffic.  No manipulation or substitution is
   performed; the MAC address supplied in all DLEP Messages is used as
   the Destination MAC address for frames emitted by the participating
   router.  MAC addresses MUST be unique within the context of router-
   modem session.

   DLEP specifies UDP multicast for single-hop discovery signaling, and
   TCP for transport of the Messages.  Modems and routers participating
   in DLEP sessions MUST have topologically consistent IP addresses
   assigned.  It is RECOMMENDED that DLEP implementations utilize IPv6
   link-local addresses to reduce the administrative burden of address
   assignment.

   To enforce the single Layer 2 domain for DLEP Messages (TCP traffic),
   implementations MUST adhere to the Generalized TTL Security Mechanism
   documented in [RFC5082] for all DLEP Messages.

   In order to keep the DLEP discovery Signals, which are multicast UDP-
   based, limited to the same Layer 2 domain, implementations MUST set
   the TTL of all DLEP Signals to 1, and MUST check for TTL = 1 on
   receipt of DLEP Signals.  Any signal received with a TTL not equal to
   1 MUST be discarded.
	
Cheers,
Neil

-----Original Message-----
From: Rick Taylor [mailto:[email-masked]] 
Sent: Tuesday, July 19, 2016 3:56 PM
To: [email-masked]; Viberg, Neil
Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement

Hi Neil,

Comments inline...

> difficult. In addition, the only way to see the TTL from a socket call 
> is to use raw sockets AFAIK. Is that the correct? Is that the intent?

That is the intent.  Using UDP TTL of 1 is to prevent multihop discovery messages from even reaching the modem.  Working it through, it would be possible for a 'bad' implementation to force discovery messages to traverse multiple hops, with the receiver seeing a TTL of 1, but that is caught by the TTL 255 requirement on the connection.  

A well-behaved implementation will set a TTL of 1 preventing unnecessary routing of packets even if using a non-link-local address. 

This is not RFC 5082 behaviour but a mechanism to prevent multi-hop discovery.

Using TTL 255 for the TCP connection is to detect and guarantee that the TCP peer is only one hop away, as defined by RFC 5082.

> problem is that a DLEP message is a logical construction received over 
> a TCP byte stream and the byte stream doesn’t inherently have a TTL. 
> How does that work? RFC 5082 seems more logical, all packets received 
> as part of the TCP session must have a TTL of 255. That is clear. How 
> does a programmer, using sockets, determine that each of the TCP 
> packets has a TTL of 255? There doesn’t appear to be any sockopts that 
> can set that requirement and I doubt many people are going to write 
> their own TCP stack or mangle an existing one to get that done. Again, 
> how is that supposed to work?

I know a reasonably modern Linux has a user-mode socket ioctl (IP_MINTTL - https://lwn.net/Articles/379070/) to restrict the TTL on a socket, and ioctl(IP_TTL) can be used with UDP to get the datagram TTL.
 Other operating systems may have similar behaviour.

The intent is to enforce the single layer-2 connectivity requirement,
preventing: a) The discovery of modems more than 1 hop away, and b) establishing a TCP connection to a modem more than 1 hop away.

Hope that helps,

Rick

---

From: Henning Rogge <[email-masked]>
Date: Wed, 20 Jul 2016 07:50:39 +0200

Quote from "man 7 ip":

       IP_RECVTTL (since Linux 2.2)
             When this flag is set, pass a IP_TTL control message with
the time-to-live field of the received  packet  as  a  byte.   Not
supported  for
             SOCK_STREAM sockets.

So we cannot easily check the TTL value on the TCP streams ( because
we don't receive them per packet).

Doing crazy things with the TTL is unnecessary anyways if you stick
with linklocal addresses. If they get forwarded, your intermediate
routers are defect.

Henning

---

From: Rick Taylor <[email-masked]>
Date: Wed, 20 Jul 2016 08:15:42 +0000

Henning,

For TCP sockets: IP_MINTTL not IP_RECVTTL.  Unfortunately IP_MINTTL
does not seem to have made it into the man ip(7) info.  It was designed
to solve the problem for BGP implementations, and definitely works for
TCP: see https://lwn.net/Articles/379070/

I believe the IP_MINTTL idea came from (Free?)BSD, so BSD's most likely
have it.

Cheers,

Rick

On Wed, 2016-07-20 at 07:50 +0200, Henning Rogge wrote:
> > You've cleared up my question on TCP. I was looking at sockopts not
> > ioctls, so, thank you for that information. Your line about "Other
> > operating systems may have similar behaviour" may be a little
> > worrying to those that don't use Linux but presumably they will
> > weigh in if it is an issue.
> > 
> >           To enforce the single Layer 2 domain, implementations
> > MUST support the Generalized TTL Security Mechanism [RFC5082].
> > 
> > makes a blanket statement without constraint to UDP or TCP. I would
> > normally interpret it as applying to all data exchanges since the
> > RFC can apply to both TCP and UDP.
> > 
> > It may clearer if:
> > 
> > > call
> > discovery messages from even reaching the modem.  Working it
> > through, it would be possible for a 'bad' implementation to force
> > discovery messages to traverse multiple hops, with the receiver
> > seeing a TTL of 1, but that is caught by the TTL 255 requirement on
> > the connection.
> > 
> > Using TTL 255 for the TCP connection is to detect and guarantee
> > that the TCP peer is only one hop away, as defined by RFC 5082.
> > 
> > > 
> > > 
> > > over
> > (IP_MINTTL - https://lwn.net/Articles/379070/) to restrict the TTL
> > on a socket, and ioctl(IP_TTL) can be used with UDP to get the
> > datagram TTL.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 20 Jul 2016 12:19:31 +0200

> TCP: see https://lwn.net/Articles/379070/

*reading the article*

> I believe the IP_MINTTL idea came from (Free?)BSD, so BSD's most likely

It seems Linux never implemented IPV6_MINHOPLIMIT, which means we
cannot use this strategy for IPv6.

I checked the current "linux stable" tree.

Henning

---

From: Rick Taylor <[email-masked]>
Date: Sat, 23 Jul 2016 08:21:27 +0000

All,

There will be an update to DLEP to include Neil’s suggested text, pointing out that RFC 5028 (TLL 255) is only applied to the TCP connection, and TTL 1 is required for the UDP discovery phase, unless IPv6 link-local addressing is in use.

After some further investigation, for those using Linux, there are socket options (setsockopt) for both IPv4 and IPv6 non-root user-mode sockets to handle all these cases:

IP_RECVTTL - To check the TTL == 1 on UDP packets.
IP_MINTTL - To enforce the TTL == 255 on TCP/IPv4 sockets.
IPV6_MINHOPCOUNT - To enforce the TTL == 255 on TCP/IPv6 sockets.

Hopefully, these changes and this cross reference should help.

Regards,

Rick

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 20 July 2016 06:51
To: Viberg, Neil
Cc: Rick Taylor; [email-masked]
Subject: Re: [manet] DLEP-23 addition of RFC 5082 requirement

Quote from "man 7 ip":

So we cannot easily check the TTL value on the TCP streams ( because we don't receive them per packet).

Doing crazy things with the TTL is unnecessary anyways if you stick with linklocal addresses. If they get forwarded, your intermediate routers are defect.

Henning

On Wed, Jul 20, 2016 at 1:59 AM, Viberg, Neil <[email-masked]> wrote:
>> call is to use raw sockets AFAIK. Is that the correct? Is that the intent?
>
>> over a TCP byte stream and the byte stream doesn’t inherently have a TTL.
>> packets has a TTL of 255? There doesn’t appear to be any sockopts 
>> that can set that requirement and I doubt many people are going to 
>> write their own TCP stack or mangle an existing one to get that done. 
>> Again, how is that supposed to work?
>

---

From: Henning Rogge <[email-masked]>
Date: Sat, 23 Jul 2016 10:24:26 +0200

> IPV6_MINHOPCOUNT - To enforce the TTL == 255 on TCP/IPv6 sockets.

We should put these into an appendix, they are a pain to find unless
you know them already. Maybe also put the necessary socket options to
SET the TTL on posix systems.

Henning Rogge