REMINDER: IETF 114 Early Bird Deadline is Monday, June 6, 2022
IETF 114 Philadelphia and online July 23-29, 2022 Hosted by Comcast and NBCUniversal 1. Registration 2. Social Event 3. Reservations 4. Fee Waivers 5. Childcare 6. Hackathon 7. COVID Management 1. Registration Early Bird Deadline The early bird deadline for registration is Monday, June 6th. Be sure to register before the deadline passes! Register online at: https://registration.ietf.org Early Bird Full Week Rates: Onsite Early-Bird Registration: USD 700, if paid in full prior to 23:59 UTC 2022-06-06 Remote Early-Bird Registration: USD 230, if paid in full prior to 23:59 UTC 2022-06-06 NOTE: Payment is required at the time of registration. The Early Bird registration fee is until this Monday, June 6th at UTC 23:59. After June 6th at UTC 23:59 the registration fees will increase. Registration types, and fee tiers, are available at https://registration.ietf.org If you require any further information or assistance with registration then please feel free to contact us at supp...@ietf.org. 2. Social Event Thanks to our hosts Comcast and NBCUniversal, we will have an excellent social event on the evening of 26 July. The social event will be held at the Barnes Foundation, with access to one of the finest Impressionist and post-Impressionist collections. A wonderful array of food, alcoholic and non-alcoholic beverages will be served. Local rules and regulations for COVID management will be followed at the IETF 114 Social Event, including mask policies for attendees and Barnes Foundation staff. Cost: $25 per ticket Limit: Two per attendee Social Event information: https://www.ietf.org/how/meetings/114/social/ Social tickets will be available during registration on your attendee dashboard. You must first register for IETF 114 to purchase a social ticket. 3. Reservations The IETF 114 meeting venue is the Sheraton Philadelphia Downtown. As explained in the FAQ, you will need to register before you can reserve a guest room at the venue. A link to reserve a guest room will be sent to you after you register. https://www.ietf.org/how/meetings/114/faq/ 4. Fee Waivers We understand that not everyone can afford the IETF 114 registration fee for a variety of reasons, including issues with income, employment status and employer support, and we do not want any of these to be a barrier to participation. If you cannot afford the registration fee then please see: https://www.ietf.org/forms/114-registration-fee-waiver/ 5. Childcare Thanks to the generosity of our Diversity & Inclusion sponsors, Akamai, Cisco, Comcast, Huawei and Verisign, the IETF is offering limited onsite childcare, free to participants. Childcare services will be provided by Corporate Kids Events [1], a professional event childcare company. Participants with children ages 0-12 are invited to take advantage of this opportunity, with childcare available Saturday, 23 July through Friday, 29 July during the meeting day. More information available here: https://www.ietf.org/how/meetings/114/childcare/ 6. Hackathon The IETF is holding a Hackathon to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. When: Saturday, July 23, 2022 through Sunday, July 24, 2022 Signup for the Hackathon Onsite: https://registration.ietf.org/114/new/hackathon_onsite/ Signup for the Hackathon Remote: https://registration.ietf.org/114/new/hackathon_remote/ More information can be found here: https://www.ietf.org/how/runningcode/hackathons/114-hackathon/ Keep up to date by subscribing to: https://www.ietf.org/mailman/listinfo/hackathon The Hackathon is free to attend and open to all. Extend the invitation to colleagues outside the IETF! Descriptions and information regarding the technologies for the hackathon are located on the IETF 114 Meeting Wiki: https://trac.ietf.org/trac/ietf/meeting/wiki/114hackathon 7. COVID Management Detailed below is our recently announced COVID Management plan for IETF 114. 1. We will accept FFP2/N95 masks as proposed and will also accept KN95/KF94/FFP3 masks and locally certified equivalents. 2. We will use Meetecho for queue management as we did for IETF 113 and an improved mobile Meetecho client will be ready for IETF 114. 3. Masks must be worn without exception in the specified areas and anyone who is unable to wear one for whatever reason cannot participate onsite. We consider that our provision of remote participation reasonably allows us to implement such a restriction. 4. There will be no change to our definition of 'fully vaccinated'. 5. We will not make any changes to this plan unless required to by local regulation or if the local situation changes dramatically close to the meeting. Full details about the IETF 114 meeting are available at: https://www.ietf.org/how/meetings/114/ If you require any further information or assistance with registration then please feel fre
Routing Area Working Group (rtgwg) WG Virtual Meeting: 2022-06-21
The Routing Area Working Group (rtgwg) WG will hold a virtual interim meeting on 2022-06-21 from 08:00 to 10:00 America/Los_Angeles (15:00 to 17:00 UTC). Agenda: TBD Information about remote participation: https://meetings.conf.meetecho.com/interim/?short=fa88e00e-9a4b-43d4-8893-189b448b9ab9 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Action: Rechartered Remote ATtestation ProcedureS (rats)
The Remote ATtestation ProcedureS (rats) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Remote ATtestation ProcedureS (rats) --- Current status: Active WG Chairs: Ned Smith Nancy Cam-Winget Kathleen Moriarty Assigned Area Director: Roman Danyliw Security Area Directors: Roman Danyliw Paul Wouters Mailing list: Address: r...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/rats Archive: https://mailarchive.ietf.org/arch/browse/rats/ Group page: https://datatracker.ietf.org/group/rats/ Charter: https://datatracker.ietf.org/doc/charter-ietf-rats/ # Introduction In network protocol exchanges, it is often the case that one entity (a Relying Party) requires evidence about the remote peer (and system components [RFC4949] thereof), in order to assess the trustworthiness of the peer. Remote attestation procedures (RATS) determine whether relying parties can establish a level of confidence in the trustworthiness of remote peers, called Attesters. The objective is achieved by a two-stage appraisal procedure facilitated by a trusted third party, called Verifier, with trusted links to the supply chain. The procedures for the two stages are: * Evidence Appraisal: a Verifier applies policy and supply chain input, such as Endorsements and References Values, to create Attestation Results from Evidence. * Attestation Results Appraisal: a Relying Party applies policy to Attestation Results associated with an Attester's Evidence that originates from a trusted Verifier. The results are trust decisions regarding the Attester. To improve the confidence in a system component's trustworthiness, a relying party may require evidence about: * system component identity, * composition of system components, including nested components, * roots of trust, * an assertion/claim origination or provenance, * manufacturing origin, * system component integrity, * system component configuration, * operational state and measurements of steps which led to the operational state, or * other factors that could influence trust decisions. While domain-specific attestation mechanisms such as Trusted Computing Group (TCG) Trusted Platform Module (TPM)/TPM Software Stack (TSS), Fast Identity Online (FIDO) Alliance attestation, and Android Keystore attestation exist, there is no interoperable way to create and process attestation evidence to make determinations about system components among relying parties of different manufactures and origins. # Goals The WG has defined an architecture (draft-ietf-rats-architecture) for remote attestation. The WG will standardize formats for describing evidence and attestation results and the associated procedures and protocols to convey evidence for appraisal to a verifier and attestation results to a relying party. Additionally, the WG will standardize formats for endorsements and reference values, and may apply and/or profile existing protocols (e.g., DTLS, CoAP, or MUD) to convey them to the verifier. Formats and protocols for appraisal policy for evidence and appraisal policy for attestation results are out of scope. The WG will continue to cooperate and coordinate with other IETF WGs such as TEEP, SUIT, CoRE, ACE, and CBOR; and work with organizations in the community, such as the TCG, Global Platform, and the FIDO Alliance, as appropriate. # Program of Work The working group will develop standards supporting interoperable remote attestation procedures for system components. The main deliverables are as follows: 1. Specify use cases for remote attestation (to document and achieve WG consensus but not expected to be published as an RFC). 2. Specify augmentations to the RATS architecture (draft-ietf-rats-architecture) in support of specific attestation techniques. 3. Standardize an information model for evidence and attestations results scoped by the specified use-cases. 4. Standardize data models that implement and secure the defined information model (e.g., CBOR Web Token structures [RFC8392], JSON Web Token structures [RFC7519]). 5. If feasible, use or extend existing protocols to securely convey evidence and attestation results, or if not, then standardize interoperable protocols for this purpose. 6. Standardize interoperable data formats to securely declare and convey endorsements and reference values. Milestones: Jul 2022 - Call for adoption on Concise Reference Integrity and Endorsement Manifests Nov 2023 - Submit Concise Reference Integrity and Endorsement Manifests for publication ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
WG Review: Source Address Validation in Intra-domain and Inter-domain Networks (savnet)
A new IETF WG has been proposed in the Routing Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (i...@ietf.org) by 2022-06-13. Source Address Validation in Intra-domain and Inter-domain Networks (savnet) --- Current status: Proposed WG Chairs: Joel Halpern Assigned Area Director: Alvaro Retana Routing Area Directors: Alvaro Retana John Scudder Andrew Alston Mailing list: Address: sav...@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/savnet Archive: https://mailarchive.ietf.org/arch/browse/savnet/ Group page: https://datatracker.ietf.org/group/savnet/ Charter: https://datatracker.ietf.org/doc/charter-ietf-savnet/ Charter for SAVNET Working Group Source address validation (SAV) is one important way to mitigate source address spoofing attacks in the data plane. Therefore, it is desirable to deploy SAV in intra-domain and inter-domain networks. However, existing SAV mechanisms like uRPF-related technologies may improperly permit spoofed traffic or block legitimate traffic. The "Source Address Validation in Intra-domain and Inter-domain Networks (SAVNET)" working group will define routing protocol-independent architectures and procedures to accurately determine the valid incoming router interfaces for specific source prefixes. The accuracy of the enhancements is expected to improve upon current SAV mechanisms. The scope of the SAVNET WG includes the SAV function for both intra-domain and inter-domain networks and the validation of both IPv4 and IPv6 addresses. The WG will address intra-domain solutions first and focus on routing protocol- based mechanisms. SAVNET should avoid packet modification in the data plane. Existing control and management plane protocols should be used within existing architectures to implement the SAV function. Any modification of or extension to existing architectures or control or management plane protocols must be carried out in the working groups responsible for them and in coordination with this working group. The SAVNET WG is chartered for the following list of items: (1) Problem Statement, Use Cases, and Requirements This document should include an analysis of the current solutions and their limitations. This item may require one document to address intra-domain SAV and another to address inter-domain SAV. This document may not necessarily be published as an IETF Stream RFC, but may be maintained in draft form or on a collaborative Working Group space to support the efforts of the Working Group and help newcomers. (2) SAVNET Architecture Documents This item requires one document to address intra-domain SAV and another to address inter-domain SAV. Each document must describe the conditions under which the architecture can improve accuracy or performance with respect to existing SAV mechanisms without assuming pervasive adoption. Each document must also include the threat model addressed by the proposed architecture and a comparison to existing SAV mechanisms. (3) Definition of routing protocol-independent operation and management mechanisms to operate and manage SAV-related configurations. After each of the items above has reached WG consensus, a discussion about whether it is appropriate to continue must occur. The discussion can consider topics related to the accuracy of the mechanism and the types of attacks it can prevent. The WG Chairs will define the specific criteria and determine that rough consensus has been reached before continuing. The WG may be rechartered or closed if rough consensus is not reached. The SAVNET WG will coordinate and collaborate with other WGs as needed. Specific interactions may include (but are not limited to): * lsr for OSPFv2, OSPFv3 and IS-IS extensions * idr for BGP extensions * lsvr for BGP SPF extensions * rift for RIFT extensions Each of these other WGs can independently determine the applicability and priority of SAV to their deployments. Milestones: Nov 2022: Adopt the Problem Statement, Use Cases, and Requirements document Jul 2023: Adopt the Intra-Domain Architecture document Mar 2024: Submit the Intra-Domain Architecture document to the IESG for publication Mar 2024: Adopt operations and management for Intra-domain networks document Mar 2024: Adopt the Inter-Domain Architecture document Jul 2024: Submit operations and management for Intra-domain networks document to the IESG for publication Nov 2024: Submit the Inter-Domain Architecture document to the IESG for publication Nov 2024: Adopt operations and management for Inter-domain networks document Mar 2025: Submit operations and management for Inter-domain networks document to the IESG for publication
