Hi, A few comments on Section 5. IP Hop-Limit Limiting:
Some limited domain protocols are intended to only be used within a single IP subnet. In these cases, it may be possible to use the IP Hop-Limit to ensure that the protocol does not leak out of the subnet. By specifying that the IP Hop-Limit of packets carrying the protocol be set to a value of 1, it is possible to ensure that the protocol does not leak out of the subnet. This is because routers will decrement the Hop-Limit of packets by 1 when forwarding them, and discard the packet when it reaches zero. The approach of setting the IP Hop-Limit to 1 ensures that the protocol does leave the subnet. This approach, using a hop limit of 1, does keep packets from leaving the subnet, but doesn’t protect against off link packets from being injected into the subnet by a malicious sender. Good to clarify this. This is different from requiring the received IP Hop-Limit has a value of 255, as used in [RFC3682], which ensures that traffic cannot be spoofed from outside the subnet. I think a better reference is RFC2461. I think this introduced the idea and is standards track unlike RFC3682 that is experimental. Which option to choose (if either) depends on the specific requirements of the protocol. Bob > > On 04-Mar-25 05:48, internet-dra...@ietf.org wrote: >> Internet-Draft draft-wkumari-intarea-safe-limited-domains-04.txt is now >> available. >> Title: Safe(r) Limited Domains >> Authors: Warren Kumari >> Andrew Alston >> Éric Vyncke >> Suresh Krishnan >> Donald Eastlake >> Name: draft-wkumari-intarea-safe-limited-domains-04.txt >> Pages: 12 >> Dates: 2025-03-03 >> Abstract: >> Documents describing protocols that are only intended to be used >> within "limited domains" often do not clearly define how the boundary >> of the limited domain is implemented and enforced, or require that >> operators of these limited domains perfectly filter at all of the >> boundary nodes of the domain to protect the rest of the global >> Internet from these protocols and vice-versa. >> This document discusses some design principles and offers mechanisms >> to allow protocols that are designed to operate in a limited domain >> "fail-closed" rather than "fail-open", thereby making these protocols >> safer to deploy on the Internet. >> These mechanism are not applicable to all protocols intended for use >> in a limited domain, but if implemented on certain classes of >> protocols, they can significantly reduce the risks. >> The IETF datatracker status page for this Internet-Draft is: >> https://datatracker.ietf.org/doc/draft-wkumari-intarea-safe-limited-domains/ >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-wkumari-intarea-safe-limited-domains-04.html >> A diff from the previous version is available at: >> https://author-tools.ietf.org/iddiff?url2=draft-wkumari-intarea-safe-limited-domains-04 >> Internet-Drafts are also available by rsync at: >> rsync.ietf.org::internet-drafts >> _______________________________________________ >> I-D-Announce mailing list -- i-d-annou...@ietf.org >> To unsubscribe send an email to i-d-announce-le...@ietf.org > _______________________________________________ > Int-area mailing list -- int-area@ietf.org > To unsubscribe send an email to int-area-le...@ietf.org
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list -- int-area@ietf.org To unsubscribe send an email to int-area-le...@ietf.org
