Re: [secdir] Secdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-22
Robert Raszuk <robert@raszuk.net> Tue, 25 April 2023 07:16 UTC
Return-Path: <robert@raszuk.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B647C15154A for <secdir@ietfa.amsl.com>; Tue, 25 Apr 2023 00:16:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QX42UHdDsQnw for <secdir@ietfa.amsl.com>; Tue, 25 Apr 2023 00:16:22 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F19C151556 for <secdir@ietf.org>; Tue, 25 Apr 2023 00:16:22 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id ffacd0b85a97d-2f58125b957so4819654f8f.3 for <secdir@ietf.org>; Tue, 25 Apr 2023 00:16:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1682406980; x=1684998980; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=FRrNBG50i454QD4hLjLHtlD5kJm5r8Iho0Gs7asSRcU=; b=gAEnsMz7V1WFQtv2DS5D54eyxU1QpUq1i/Z++1prlku7MXiPSfB5BRNxo5P7iKKPgV 1YrCX3Yr0bfMriNcNgqSAPhzvmKKvDWp2RB+G9ZJdhDcoiuQBpU4BDsUARX4dW6Vh4g1 jDi+JroKM/B3R4MdyaDR9iFunxBez0zG3tsnGU7M7Z1kwySl+u9fo/Nq3ZqNRuFO1QhC JuFA7bEfmv+3tao/ES9mpXNPlRyCi2kGfYRlZWG2jQPgFhisIorrLq7WnN7DV996Vi2C Ufa+81MuC91snaCnf0ZBYcUGOQWtB3G4tx+GZp4vZ+rW7LwCH5uZ6iDZ8XV9OCjKg9VS 3q4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682406980; x=1684998980; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=FRrNBG50i454QD4hLjLHtlD5kJm5r8Iho0Gs7asSRcU=; b=Ty3KHsWqajZhTRd5DMwSh958pTLTTMpzfB8xsdsZia6QcOYVT/Xl1OZke2oSR3cXTB 6XS/9RpBHWCCM6lJVsRE0ZuItAzgqktWkT8O5AfOxUYcXKZ6CLLUkrx3cWrm3R8kdwC9 FjM1iCeXLaSZrr9ENJIGRDGtcIbg/pQWo7gmB+rcy4pZECRWye1v+gXvt6kdmEfipd/a mzKZWki0bdtkNnYI8AE3Yq3TTC0TyCljqb9yjTOpBfL/QvMUGe++rM/uadECQgUshSlG +tPmdf9hWJenSBFehh+8rXSB1fjtI2JrleNKgVXIo85yJk4lVzVoJ9Sm+eOJO/2pagTm 2lPg==
X-Gm-Message-State: AAQBX9dv6sYnHuwRnyGcALCkBKL2GWRu7YCj/YP2qmj6+eaGlBbXuxfh ig+A4g2G8UbBr0Tr9fdyMMR9hO54nQ6eong3fxLamg==
X-Google-Smtp-Source: AKy350azTEHIiFrwUrNU6inE0gNbnobVk0Xj8sC6mbJ0//OLBDoru7y4nUMPVEzsoxZhvw56wzJeObUqQj+XJIgOMzU=
X-Received: by 2002:adf:f712:0:b0:2f4:170:3807 with SMTP id r18-20020adff712000000b002f401703807mr12237234wrp.44.1682406980217; Tue, 25 Apr 2023 00:16:20 -0700 (PDT)
MIME-Version: 1.0
References: <168103791733.43307.11737105219506688508@ietfa.amsl.com> <643A15FC-6BFB-4723-93C4-6ECA22C128FE@gmail.com> <CO1PR13MB492092C6FEF537BB817A25F8859B9@CO1PR13MB4920.namprd13.prod.outlook.com> <CAGgd1OcSzYtfCFO5sVG_VhZuCwU0FWj-xyYRp=r7rJ41B+i5rg@mail.gmail.com> <CAGgd1Ofuau_y5x1TznUuOBrjM+BX4MrJ-iP8rTZnGc6VFOZ7+Q@mail.gmail.com> <CO1PR13MB4920D4AC874DE8A007E2FC2A85679@CO1PR13MB4920.namprd13.prod.outlook.com> <598327D8-E9D8-492E-A5B0-FD134EB19A0A@mit.edu> <CO1PR13MB49206255AD7771A1B499064085649@CO1PR13MB4920.namprd13.prod.outlook.com> <A1FDB15C-AE02-45EF-8F1B-9BC9168939B9@mit.edu> <CAOj+MMHLJcDE2028vyJOUBjE80Sxks5NzR-f1ohNerx2_beNog@mail.gmail.com> <769944E3-5835-454F-8004-B764299CDC21@mit.edu>
In-Reply-To: <769944E3-5835-454F-8004-B764299CDC21@mit.edu>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 25 Apr 2023 09:16:09 +0200
Message-ID: <CAOj+MMFjcD8ULymF1Q18qVZU73A0Mf3C+c7_u54cTyZuAoPMuA@mail.gmail.com>
To: Uri Blumenthal <uri@mit.edu>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, Deb Cooley <debcooley1@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org" <draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006c841005fa23e6d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/7HuLmr0fpfaQmv_-bUf3xDYl53A>
Subject: Re: [secdir] Secdir early review of draft-ietf-rtgwg-net2cloud-problem-statement-22
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Apr 2023 07:16:27 -0000
Well - let's be fair - IPSec is just one option. I would just say you should encrypt your traffic if it is being sent over public network. I would leave the choice of protocol to the user and public cloud edge. We seems to fully agree in respect to other points. Best, R. On Tue, Apr 25, 2023 at 9:12 AM Uri Blumenthal <uri@mit.edu> wrote: > Robert, > > Yes, I think we're in complete agreement. > > One thing I'm not sure I understand is where public Internet fits here. > > Perhaps, all that needs to be said is something like "you should tunnel > your traffic via IPsec through public Internet segments, if they are > present"? And, as I mentioned before, augment Security Considerations? > > Thx > > On Apr 25, 2023, at 02:35, Robert Raszuk <robert@raszuk.net> wrote: > > > Hi Uri, > > > from the security point of view MPLS is useless over the public Internet > > Well MPLS does not operate natively over public Internet - never did - > never will.** > > For this discussion it is important to recognize that MPLS-VPNs provide > traffic isolation no security. Only early days some marketing slides were > trying to say that MPLS-VPN security is high .. but all they meant to say > was that all they provide is isolation and as good as ATM or Frame Relay. > > So comparing IPSec or DTLS or wireguard or LISP+Sec etc ... to closed > domains VPNs is not comparing apples to apples. > > ** Sure one could send MPLS VPN labeled packets (used for demux) over IP > tunneling (replacing MPLS transport with IP transport), but this needs to > also be accompanied by signalling and whoever sends this needs to own > the remote demux point. > > Best, > Robert > > > On Tue, Apr 25, 2023 at 4:37 AM Uri Blumenthal <uri@mit.edu> wrote: > >> From the performance and QoSv points of view, MPLS is a winner, no >> questions. >> >> But if my understanding is correct, from the security point of view MPLS >> is useless over the public Internet - it's applicable only when the network >> path is composed exclusively of trusted collaborating providers. And even >> then - with the caveats I mentioned. >> >> Perhaps, you may want to >> 1. Replace "minimize ... over" with "limit ... to"; >> 2. Add the caveats I listed to the Security Considerations. >> >> Thnx >> >> On Apr 24, 2023, at 20:13, Linda Dunbar <linda.dunbar@futurewei.com> >> wrote: >> >> >> >> Uri, >> >> >> >> I see your points. How about changing the sentence to: >> >> *As the private VPNs provide higher quality of services, choosing a PE >> closest to the Cloud GW for the IPsec tunnel is desirable to minimize the >> IPsec tunnel distance over the public Internet.* >> >> >> >> >> >> Linda >> >> *From:* Uri Blumenthal <uri@mit.edu> >> *Sent:* Monday, April 24, 2023 6:02 PM >> *To:* Linda Dunbar <linda.dunbar@futurewei.com> >> *Cc:* Deb Cooley <debcooley1@gmail.com>; secdir@ietf.org; >> draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org; rtgwg@ietf.org >> *Subject:* Re: [secdir] Secdir early review of >> draft-ietf-rtgwg-net2cloud-problem-statement-22 >> >> >> >> Linda, >> >> I respectfully disagree with your statement that MPLS VPN is more secure >> than IPsec. >> >> >> >> IPsec is end-to-end protection, immune by design to any action by the >> (potentially hostile part of the) infrastructure. As long as the connecting >> nodes correctly implement the protocol, it is secure, period. >> >> >> >> MPLS is only as secure as the infrastructure it's running on, depending >> on every switch between the end-points be ok, not compromised, etc. In >> other words, it's enough to compromise one switch that is handling your >> traffic to bring security down to zero. >> >> >> >> You could argue that switches are more secure than end-boxes or routers >> that hold IPsec connections. My answer would be - it depends. >> >> >> >> In summary: no, MPLS is less, not more, secure than IPsec. >> >> >> >> On Apr 24, 2023, at 16:54, Linda Dunbar <linda.dunbar@futurewei.com> >> wrote: >> >> >> >> Deb, >> >> >> >> Thank you for the additional comments. >> >> >> >> Resolutions to your comments are inserted below: >> >> >> >> Linda >> >> >> >> *From:* Deb Cooley <debcooley1@gmail.com> >> *Sent:* Thursday, April 20, 2023 9:44 AM >> *To:* Linda Dunbar <linda.dunbar@futurewei.com> >> *Cc:* secdir@ietf.org; >> draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org; rtgwg@ietf.org >> *Subject:* Re: [secdir] Secdir early review of >> draft-ietf-rtgwg-net2cloud-problem-statement-22 >> >> >> >> Apologies, it has been a busy week...I recognize that writing a draft like this is difficult. >> >> My remaining concerns are: >> >> Section 4, sentence 1: Grammar - 'will be mixed of different' should be 'will >> >> be a mix of different'. >> >> This now says 'a mixed of different'. Most definitely the smallest of nits. >> >> [Linda] thanks for catching it. >> >> New: Section 4.3, para 3: I am unfamiliar with MPLS VPNs, are they really 'more secure' than IPSec? I can easily believe that they have better quality services, and may perform better. >> >> [Linda] Section 4.3 has now changed “Extending Private VPNs to Hybrid Cloud DCs.”. Private VPNs, including private circuits, MPLS based VPN, use network service provider’s physical links/wavelengths. Their traffic running over Private VPNs don’t mix with Internet traffic. Therefore, more secure. >> >> >> >> New: Section 5.1: The discussion about the security risk of IPSec group encryption should be added to section 7. >> >> >> >> [Linda] Section 5.1 is about Scaling IPsec, instead of Pairwise Tunnels which needs N square number of tunnels, the draft suggest improvement. >> >> >> >> >> >> Deb Cooley >> >> >> >> On Fri, Apr 14, 2023 at 6:51 AM Deb Cooley <debcooley1@gmail.com> wrote: >> >> I'm including my final set of comments. I made the mistake of submitting the wrong version. I've noted the ones you have addressed already in blue. I apologize for the confusion. >> >> >> >> I have 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 editors and WG chairs should treat >> >> these comments just like any other last call comments. >> >> >> >> Document: draft-ietf-rtgwg-net2cloud-problem-statement-22 <https://datatracker.ietf.org/doc/draft-ietf-rtgwg-net2cloud-problem-statement/22/> >> >> Reviewer: Deb Cooley >> >> Review Date: 2023-04-06 (early review) >> >> >> >> Please note that I know almost nothing about BGP, MPLS or routing. >> >> >> >> The summary of the review is 'not ready'. >> >> >> >> Section 3: perhaps move this whole section to Section 7? Sections 4, 5, and 6 >> >> seem like they should come before Section 3 anyway? >> >> >> >> partially done (moved Section 3.5 to 7) >> >> >> >> Section 3.1, para 1, sentence 2: Grammar: 'with more variety of parties' could >> >> be 'with a larger variety of parties.' >> >> >> >> Apologies, I meant this sentence: 'Cloud GWs need to peer with more variety of parties, via private circuits or IPsec over public internet.' >> >> >> >> >> >> Section 3.1, para 2, sentence 2: 'IP tunnels', does this imply IPSec? Or >> >> something else? >> >> >> >> done >> >> >> >> Section 3.1, para 3: By setting up default eBGP routes, these don't count as >> >> routes from an external entity? The rest of the paragraph addresses the >> >> handling of exceeding the maximum route threshold? But there appears to be an >> >> option to keep the BGP session? This paragraph is confusing. >> >> >> >> done >> >> >> >> Section 3.2, paragraph 2: IGP? AS? I can't tell what this is trying to say. >> >> >> >> done >> >> >> >> Section 3.2, paragraph 3: If there is a site failure, how is the Cloud GW >> >> 'running fine'? Is this GW using a different site? BFD expands to what? >> >> >> >> done - I understand... >> >> >> >> Section 3.2: Para 1 states why a site might go down. Para 2-6 outline the >> >> routing (?) issues that occur when a site goes down. I think these could be >> >> better organized. Only the last para suggests mitigations. >> >> >> >> I think most of this fits better into Section 7? >> >> >> >> Section 3.3 I'm not an expert, but isn't this an issue to any routing scenario? >> >> Can this be combined with Section 3.6? >> >> >> >> ok >> >> >> >> Section 3.4, para 3, item 1: Is this a problem? Or a feature? If it is a >> >> problem, can you say why? >> >> >> >> done - this is better! >> >> >> >> Section 3.6, last paragraph: A globally unique name won't 'resolve the same >> >> way from every perspective'? Other than being restricted (previous paragraph), >> >> what does this mean? If this is covered in the previous para, I would recommend >> >> deleting the phrase. >> >> >> >> fine >> >> >> >> Section 4, sentence 1: Grammar - 'will be mixed of different' should be 'will >> >> be a mix of different'. >> >> >> >> Section 4.2, para 2: Use of a shared key in IPSec implies that IKE isn't used >> >> (shared key was only possible with IKEv1 I believe, which is deprecated). I >> >> would remove the phrase 'using a shared key'. >> >> >> >> On Wed, Apr 12, 2023 at 4:09 PM Linda Dunbar <linda.dunbar@futurewei.com> >> wrote: >> >> Deb, >> >> >> >> We really appreciate your review and comments to the document. Please see >> below for the resolution to your comments. >> >> >> >> Linda >> >> >> >> -----Original Message----- >> From: Deb Cooley <debcooley1@gmail.com> >> Sent: Sunday, April 9, 2023 6:28 AM >> To: secdir@ietf.org; >> draft-ietf-rtgwg-net2cloud-problem-statement.all@ietf.org; rtgwg@ietf.org >> Subject: Re: [secdir] Secdir early review of >> draft-ietf-rtgwg-net2cloud-problem-statement-22 >> >> >> >> Note: I hit ‘send’ too early, ugh. Please see the comments on the >> datatracker for the correct version. >> >> >> >> Deb Cooley >> >> >> >> > On Apr 9, 2023, at 6:59 AM, Deb Cooley via Datatracker < >> noreply@ietf.org> wrote: >> >> > >> >> > Reviewer: Deb Cooley >> >> > Review result: Not Ready >> >> > >> >> > I have 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 editors and WG chairs should treat >> >> > these comments just like any other last call comments. >> >> > >> >> > Document: draft-ietf-rtgwg-net2cloud-problem-statement-22 >> >> > Reviewer: Deb Cooley >> >> > Review Date: 2023-04-06 (early review) >> >> > >> >> > Please note that I know almost nothing about BGP, MPLS or routing. >> >> > >> >> > The summary of the review is >> >> > >> >> > Section 3.1, para 1, sentence 2: Grammar: 'with more variety of >> >> > parties' could be 'with a larger variety of parties.' >> >> > >> >> [Linda] Per RTGarea Director suggestion, the text has been changed to the >> following. Is it Okay with you? >> >> *Site failures include (but not limited to) a site capacity degradation >> or entire site going down. The reasons for these capacity degradations or >> failures can include: a) fiber cut for links connecting to the site or >> among pods within the site, b) cooling failures, c) insufficient backup >> power, d) cyber threat attacks, e) too many changes outside of the >> maintenance window, or other errors. Fiber-cut is not uncommon within a >> Cloud site or between sites.* >> >> >> >> >> >> > Section 3.1, para 2, sentence 2: 'IP tunnels', does this imply IPSec? >> >> > Or something else? >> >> > >> >> [Linda] changed. >> >> >> >> > Section 3.1, para 3: By setting up default eBGP routes, these don't >> >> > count as routes from an external entity? The rest of the paragraph >> >> > addresses the handling of exceeding the maximum route threshold? But >> >> > there appears to be an option to keep the BGP session? This paragraph >> is confusing. >> >> [Linda] The intent is to say: >> >> When inbound routes exceed the maximum routes threshold for a peer, the >> current common practice is generating out of band alerts (e.g., Syslog) via >> management system to the peer, or terminating the BGP session (with cease >> notification messages [RFC 4486] being sent). However, it would be useful >> if IETF can specify some in-band alert messages to indicate the inbound >> routes exceeding the threshold. >> >> > >> >> > Section 3.2, paragraph 2: IGP? AS? I can't tell what this is trying >> to say. >> >> > >> >> [Linda] changed to domain. >> >> >> >> > Section 3.2, paragraph 3: If there is a site failure, how is the >> >> > Cloud GW 'running fine'? Is this GW using a different site? BFD? >> >> [Linda] Failures within a site like a fiber cut between two racks. So the >> GW is still running fine. >> >> >> >> > >> >> > Section 3.2: Para 1 states why a site might go down. Para 2-6 >> >> > outline the routing (?) issues that occur when a site goes down. I >> >> > think these could be better organized. Only the last para suggests >> mitigations. >> >> [Linda] changed to the "Failures within a site". >> >> >> >> > >> >> > Section 3.3 I'm not an expert, but isn't this an issue to any routing >> scenario? >> >> > Can this be combined with Section 3.6? >> >> [Linda] Section 3.3 is to introduce the problem of multiple instances >> available at different sites for one service (such as using ANYCAST >> address). The site with the shortest distance might not be the optimal >> service instance as the site might be overloaded. >> >> Section 3.6 is about DNS resolution at different sites. . >> >> >> >> >> >> > >> >> > Section 3.4, para 3, item 1: Is this a problem? Or a feature? If it >> >> > is a problem, can you say why? >> >> [Linda] Item 1 is meant to say: >> >> The difference of routing distances to multiple server instances in >> different edge Cloud is relatively small. Therefore, the edge Cloud that is >> the closest doesn’t contribute much to the performance. >> >> >> >> > >> >> > Section 3.5: I would suggest moving this to Section 7. There are a >> >> > couple of mitigations listed - anti-DDOS, DTLS, IPSec, monitoring. >> >> > >> >> [Linda] Good suggestion. Changed. >> >> >> >> > Section 3.6, last paragraph: A globally unique name won't 'resolve >> >> > the same way from every perspective'? Other than being restricted >> >> > (previous paragraph), what does this mean? If this is covered in the >> >> > previous para, I would recommend deleting the phrase. >> >> > >> >> [Linda] DNSOPS director insisted on adding this paragraph to empathize >> that not all globally unique names can be resolved. >> >> >> >> >> >> > Stopped at Section 4. >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > secdir mailing list >> >> > secdir@ietf.org >> >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww >> <https://www/>. >> >> > ietf.org%2Fmailman%2Flistinfo%2Fsecdir&data=05%7C01%7Clinda.dunbar%40f >> >> > uturewei.com%7C07fbc4f2cc284e39624f08db38ed774e%7C0fee8ff2a3b240189c75 >> >> > 3a1d5591fedc%7C1%7C0%7C638166364798968574%7CUnknown%7CTWFpbGZsb3d8eyJW >> >> > IjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000% >> >> > 7C%7C%7C&sdata=2SVXI%2BaoyU%2Bc4Aa8RRvb6BEQUIMmwTz%2BsqF6Z5o%2FnuU%3D& >> >> > reserved=0 >> >> > wiki: >> >> > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac >> <https://trac/> >> >> > .ietf.org%2Ftrac%2Fsec%2Fwiki%2FSecDirReview&data=05%7C01%7Clinda.dunb >> >> > ar%40futurewei.com%7C07fbc4f2cc284e39624f08db38ed774e%7C0fee8ff2a3b240 >> >> > 189c753a1d5591fedc%7C1%7C0%7C638166364798968574%7CUnknown%7CTWFpbGZsb3 >> >> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7 >> >> > C3000%7C%7C%7C&sdata=vbmjW7gi%2BOgn9xbql5S4grf6NZayrZ%2B%2BgFYC3%2B0yK >> >> > cE%3D&reserved=0 >> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: https://trac.ietf.org/trac/sec/wiki/SecDirReview >> >> _______________________________________________ >> rtgwg mailing list >> rtgwg@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> >
- [secdir] Secdir early review of draft-ietf-rtgwg-… Deb Cooley via Datatracker
- Re: [secdir] Secdir early review of draft-ietf-rt… Deb Cooley
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar
- Re: [secdir] Secdir early review of draft-ietf-rt… Deb Cooley
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar
- Re: [secdir] Secdir early review of draft-ietf-rt… Deb Cooley
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar
- Re: [secdir] Secdir early review of draft-ietf-rt… Uri Blumenthal
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar
- Re: [secdir] Secdir early review of draft-ietf-rt… Uri Blumenthal
- Re: [secdir] Secdir early review of draft-ietf-rt… Robert Raszuk
- Re: [secdir] Secdir early review of draft-ietf-rt… Uri Blumenthal
- Re: [secdir] Secdir early review of draft-ietf-rt… Robert Raszuk
- Re: [secdir] Secdir early review of draft-ietf-rt… Uri Blumenthal
- Re: [secdir] Secdir early review of draft-ietf-rt… Deb Cooley
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar
- Re: [secdir] Secdir early review of draft-ietf-rt… Deb Cooley
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar
- Re: [secdir] Secdir early review of draft-ietf-rt… Deb Cooley
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar
- Re: [secdir] Secdir early review of draft-ietf-rt… Deb Cooley
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar
- Re: [secdir] Secdir early review of draft-ietf-rt… Deb Cooley
- Re: [secdir] Secdir early review of draft-ietf-rt… Linda Dunbar