Hi Russ, Thank you for these comments, and see below for discussion:
> -----Original Message----- > From: Russ Housley via Datatracker <[email protected]> > Sent: Tuesday, September 16, 2025 8:44 AM > To: [email protected] > Cc: [email protected]; [email protected] > Subject: [rtgwg] draft-ietf-rtgwg-atn-bgp-28 early Secdir review > > Document: draft-ietf-rtgwg-atn-bgp > Title: A Simple BGP-based Mobile Routing System for the Aeronautical > Telecommunications Network > Reviewer: Russ Housley > Review result: Has Issues > > I reviewed this document as part of the Security Directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the Security Area > Directors. Document authors, document editors, and WG chairs should > treat these comments just like any other IETF Last Call comments. > > Document: draft-ietf-rtgwg-atn-bgp-28 > Reviewer: Russ Housley > Review Date: 2025-09-16 > Review Due: 2025-09-22 > IETF LC End Date: Unknown > IESG Telechat date: Unknown > > > Summary: Has Issues > > > Major Concerns: > > Section 3 says that ASNs will be allocated and managed by an ATN/IPS > assigned numbers authority established by ICAO. Will this authority > operate an RPKI? If so, it should be discussed here or in Section 10. This text is old and perhaps overcome by inertia; I am not aware of any efforts by ICAO to establish an assigned numbers authority for ASNs nor to operate an RPKI. Instead, I would like to re-factor the text to advocate for ASN allocations per standard Internetworking practices the same as for any Internet autonomous system BGP routers. Would something like that be acceptable? > Minor Concerns: > > Section 1 talks about "secured direct point-to-point links and/or > secured tunnels". Please say what you mean by secured. Based on the > discussion in Section 10, you expecting confidentiality, integrity, and > authentication. MACsec is not a point-to-point link, but is seems that > it would meet the needs of this architecture. Is MACsec accommodated? For secured tunnels, the document references IPsec as an example securing service, but I don't mind making that mandatory by removing the "e.g."; would mandating IPsec for secured tunnels be useful. For secured direct point-to-point links the intention was that these would be subject to physical security but I don't mind also employing a higher layer service like MACsec to provide multiple layers of security. Is there a reference for MACsec that the document could cite? > Nits: > > Section 1: s/aviation data link they/aviation data link, they/ > > Section 1: s/Stable Network Prefixes SNPs/Stable Network Prefixes (SNPs)/ > > Section 3: s/Since ATN/ATN/ > > Section 4: s/WiFi/Wi-Fi/ > > Section 5: s/In the first figure/In Figure 5/ > > Section 5: s/In the second figure/In Figure 6/ Yes, these are all good catches and will be corrected in the next document version. Thank you - Fred Templin > > _______________________________________________ > rtgwg mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
