[OPSEC]Re: Sunsetting the OPSec WG: It's Been a Secure Ride!

[KK Chittimaneni]

Thank you to everyone who contributed to this WG over the years.

Best Regards,
KK

On Tue, Jul 30, 2024 at 9:07 AM Bill Woodcock  wrote:

> Indeed!  Thanks so much, Jen, Ron, Warren.  It’s been a great forum for
> network operators within the IETF, and has provided invaluable nudges
> forward in the transition to IPv6.  And RFC7454 is one of the staples in
> educating new BGP-speakers.  I hope to see all of us working in other areas
> around the IETF.  Best wishes, everyone!
>
> -Bill
>
> > On Jul 30, 2024, at 16:31, Eric Vyncke (evyncke)  40cisco@dmarc.ietf.org> wrote:
> >
> > Also a tear or two in my eyes when reading this...
> >  Thank you to Jen, Ron, and Warren
> >  -éric
> >  PS: what is the status of the mailing list ? Will it be kept open ?
> >  From: Jen Linkova 
> > Date: Friday, 26 July 2024 at 19:41
> > To: opsec WG 
> > Cc: OpSec Chairs , Warren Kumari <
> war...@kumari.net>
> > Subject: [OPSEC]Sunsetting the OPSec WG: It's Been a Secure Ride!
> > Hello,
> >
> > With security woven into every modern IETF protocol (like a comfy
> > security blanket), this group has been unsurprisingly quiet lately.
> >
> > So, with a touch of nostalgia (and maybe a tear or two), the chairs
> > and the responible AD have decided it's time to say farewell to the
> > OpSec WG.
> >
> > The mail archive reveals the very first email was sent to this list on
> > December 19th, 2007—back when flip phones were still cool!
> >
> > It's been a fantastic 16 years. The group has published 18 RFCs,
> > making the internet (and, most importantly, IPv6) a safer and
> > all-around more awesome place.
> >
> > A massive thank you to everyone for their contributions and hard work!
> >
> > ---
> > Ron, Jen and Warren
>
>
>
>
> ___
> OPSEC mailing list -- opsec@ietf.org
> To unsubscribe send an email to opsec-le...@ietf.org
>
___
OPSEC mailing list -- opsec@ietf.org
To unsubscribe send an email to opsec-le...@ietf.org

Re: [OPSEC] Alvaro Retana's No Objection on draft-ietf-opsec-v6-25: (with COMMENT)

[KK Chittimaneni]

Hi Alvaro,

Thank you very much for your detailed review.

Together with my co-authors, we have uploaded revision -27, which should
address all your comments.

The diff is at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-27

Regards,
KK

On Mon, Apr 19, 2021 at 8:27 AM Alvaro Retana 
wrote:

> Enno:
>
> Hi!
>
> I looked at -26.
>
> I still find the applicability statement confusing, the the reasons I
> described in 1.a/1.b (below).  There is a contradiction about whether the
> document applies to residential users (as mentioned in §1.1 and §5) or not
> (as mentioned in the Abstract).  Also, why does the "applicability
> statement especially applies to Section 2.3 and Section 2.5.4” *only*?
>
> This is obviously a non-blocking comment, but I believe it is important
> since the applicability statement may influence who reads and follows the
> recommendations.
>
> Thanks!
>
> Alvaro.
>
> On April 10, 2021 at 2:36:26 PM, Enno Rey (e...@ernw.de) wrote:
>
> Hi Alvaro,
>
> thanks for the detailed evaluation and for the valuable feedback.
>
> I went thru your COMMENTS and performed some related adaptions of the
> draft. A new version has been uploaded.
>
> thank you again & have a great weekend
>
> Enno
>
>
>
>
> On Mon, Apr 05, 2021 at 02:07:53PM -0700, Alvaro Retana via Datatracker
> wrote:
> > Alvaro Retana has entered the following ballot position for
> > draft-ietf-opsec-v6-25: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/
> >
> >
> >
> > --
> > COMMENT:
> > --
> >
> >
> > (1) The applicability statement in ??1.1 is confusing to me.
> >
> > a. The Abstract says that "this document are not applicable to
> residential
> > user cases", but that seems not to be true because this section says
> that the
> > contents do apply to "some knowledgeable-home-user-managed residential
> > network[s]", and ??5 is specific to residential users.
> >
> > b. "This applicability statement especially applies to Section 2.3 and
> Section
> > 2.5.4." Those two sections represent a small part of the document; what
> about
> > the rest? It makes sense to me for the applicability statement to cover
> most
> > of the document.
> >
> > c. "For example, an exception to the generic recommendations of this
> document
> > is when a residential or enterprise network is multi-homed." I'm not
> sure if
> > this sentence is an example of the previous one (above) or if "for
> example" is
> > out of place.
> >
> > (2) ??5 mentions "early 2020" -- I assume that the statement is still
> true now.
> >
> > (3) It caught my attention that there's only one Normative Reference
> (besides
> > rfc8200, of course). Why? What is special about the IPFIX registry?
> >
> > It seems that an argument could be made to the fact that to secure
> OSPFv3, for
> > example, an understanding of the protocol is necessary. This argument
> could be
> > extended to other protocols or mechanisms, including IPv6-specific
> technology:
> > ND, the addressing architecture, etc. Consider the classification of the
> > references in light of [1].
> >
> > [1]
> >
> https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
> >
> >
> >
>
> --
> Enno Rey
>
> Cell: +49 173 6745902
> Twitter: @Enno_Insinuator
>
>
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] Roman Danyliw's No Objection on draft-ietf-opsec-v6-26: (with COMMENT)

[KK Chittimaneni]

Hi Roman,

Thank you very much for your detailed review.

Together with my co-authors, we have uploaded revision -27, which should
address most of your comments except a few listed below with our rationale:

** Section 2.1.5.  Per “However, in scenarios where anonymity is a strong
desire (protecting user privacy is more important than user attribution),
privacy extension addresses should be used.”, it might be worth
acknowledging
that even if these are managed network, the end user and the operators may
be
at odds on what privacy properties are important.

[authors] We didn't change the text here as we felt that this is a given.

** Section 3.1.  This list is helpful.  Is text here and Section 2.5.4
needed?
For example, does one need to say both “discard _packets_ from bogons” (this
section) and “discard _routes_ from bogons” (Section 2.5.4)

[authors] We kept the text in both sections the rationale being that
packets are dropped at the enterprise edge while routes are ignored by
peering routers (not all enterprises have a DFZ routing)

The diff is at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-27

Regards,
KK

On Tue, Apr 20, 2021 at 7:11 PM Roman Danyliw via Datatracker <
nore...@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-opsec-v6-26: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/
>
>
>
> --
> COMMENT:
> --
>
> ** Section 2.1.5.  Per “However, in scenarios where anonymity is a strong
> desire (protecting user privacy is more important than user attribution),
> privacy extension addresses should be used.”, it might be worth
> acknowledging
> that even if these are managed network, the end user and the operators may
> be
> at odds on what privacy properties are important.
>
> ** Section 2.2.1.  Per “A firewall or edge device should be used to
> enforce the
> recommended order and the maximum occurrences of extension headers”, does
> enforcement mean dropping the packets?
>
> ** Section 2.3.2.  Per “Network operators should be aware that RA-Guard and
> SAVI do not work or could even be harmful in specific network
> configurations”,
> please provide a more details, ideally through citation.
>
> ** Section 2.3.2, “Enabling RA-Guard by default in … enterprise campus
> networks
> …”, what’s the key property of “enterprise campus network”.  The
> introduction
> already roughly says this whole document applies to managed networks.
>
> ** Section 2.5.2.  Reading this section, the specific recommended practices
> weren’t clear.
>
> ** Section 2.6.  It wasn’t clear how comprehensive this list of logs was
> intended to be.  A few additional thoughts include: -- DHCPv6 logs --
> firewall
> ACL logs -- authentication server logs -- NEA-like policy enforcement at
> the
> time of connection -- vpn/remote access logs -- passive DNS from port 53
> traffic -- full packet capture -- active network and service scanning/audit
> information
>
> ** Section 2.6.1.2.  The recommended fields in this section are helpful,
> but
> only in the context of the rest of the five-tuple + timing + interface +
> vlan +
> select layer 4 information for each flow.  These open IPFIX information
> elements aren't mentioned.
>
> ** Section 2.6.2.1.  Per “The forensic use case is when the network
> operator
> must locate an IPv6 address that was present in the network at a certain
> time
> or is currently in the network”, isn’t this use case more precisely an
> attempt
> to link an IP address to (a) a specific port in the case of a wired
> network;
> (b) a access point (or base station, etc.) in the case of wireless; or (c)
> an
> external IP address in the case of a VPN connection?
>
> ** Section 2.6.2.1.  Additional techniques/suggestions to consider:
> -- Using the IPAM system noted in Section 2.1 or any other inventory
> system to
> provide hints in the about where an IP address might belong in the
> topology.
>
> -- A reminder that mapping between and IP+port or MAC+IP might not have
> been
> the same one as during the time of the event of interest
>
> -- there is discussion about identifying subscribers for an ISP but not in
> normal enterprise network scenario through SSO logs (if port level security
> doesn’t exist)
>
> ** Section 2.6.2.2.  Per “The first technique is to use the IPFIX
> information
> and extract the list of all IPv6 source addresses to find all of the IPv6
> nodes
> that sent packets through the router”.  This framing 

Re: [OPSEC] Zaheduzzaman Sarker's No Objection on draft-ietf-opsec-v6-25: (with COMMENT)

[KK Chittimaneni]

Hello Zahed,

Thank you very much for your detailed review.

Together with my co-authors, we have uploaded revision -27, which should
address all your comments.

The diff is at: https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-27

Regards,
KK

On Wed, Apr 7, 2021 at 3:33 AM Zaheduzzaman Sarker via Datatracker <
nore...@ietf.org> wrote:

> Zaheduzzaman Sarker has entered the following ballot position for
> draft-ietf-opsec-v6-25: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/
>
>
>
> --
> COMMENT:
> --
>
> I found this document very informative and I learned quite a lot by reading
> this document (I must confess I haven't  read the long list of  referenced
> documents :-)). I think the collected recommendations in one place will be
> very
> helpful.
>
> Some comments -
>
>   *  The abstract says - "The recommendations in this document are not
>   applicable to residential user cases". However, later on in section 1.1
> it
>   says - "This covers Service Provider (SP), enterprise networks and some
>   knowledgeable-home-user-managed residential network." Furthermore in
> section
>   5, it recommends configurations for residential users.May be I am not
>   getting the distinction among residential user cases, managed residential
>   network and residential users correct but I think further clarification
> is
>   needed on what is written in thee abstract and what is in the rest of the
>   document.
>
>   * I noted that section 2.3.4 refers to 3GPP 4G terminologies while
> describing
>   the case. If this section is not supposed to restricted to certain
>   generations of 3GPP technologies then I would recommend to update the
> section
>   with 5G terminologies as well.
>
>   * In section 2.6 there is an ask for the network operators to log "of all
>   applications using the network (including user space and kernel space)
> when
>   available (for example web servers)". How realistic is this? I hardly
> see the
>   web servers sharing logging files with network operators ( I would be
> happy
>   to be corrected here ). I am also missing the discussion on -- if not
>   available how much this affects the forensic research in the event of
>   security incident and abnormal behavior.
>
>
>
>
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-20.txt

[KK Chittimaneni]

Hi Gyan,

No IPRs on my end.

Thanks,
KK

On Thu, Oct 24, 2019 at 11:36 AM Gyan Mishra  wrote:

> Hi Eric
>
> I am completing the Shepards writeup in essay format. Plan to submit in
> the next few days.
>
> As far as WG consensus and history on the document from its initial I-D
> state were there any nits other then what is public in the tracker or any
> WG consensus issues or topics discussed that I should be aware of to
> include in the write up.  I assume we finally reached WG consensus on all
> topics with no outstanding issues as we are now ready to publish.
>
> Are there any IPRs disclosed or outstanding.
>
> Regards,
>
> Gyan
>
> Sent from my iPhone
>
> > On Oct 15, 2019, at 2:12 AM, Eric Vyncke (evyncke) 
> wrote:
> >
> > Gyan,
> >
> > Thank you very much for being 'victimteered' as the document shepherd
> [1] __
> >
> > Thank you Jen and Ron for your support
> >
> > Regards
> >
> > -éric and the authors -kk -merike -enno
> >
> > [1] see
> https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/edit/shepherdwriteup/
> (you need to create a free account on datatracker if not yet done), the
> mailing list archive should also be a source of information
> https://mailarchive.ietf.org/arch/browse/opsec/?q=draft-ietf-opsec-v6
> >
> >
> > On 15/10/2019, 01:54, "Gyan Mishra"  wrote:
> >
> >Ron
> >
> >I read the document thoroughly in its entirety and do have valuable
> real world experience in this space so I am volunteering.
> >
> >Not sure what I am getting myself into.😀
> >
> >Gyan
> >
> >Sent from my iPhone
> >
> >> On Oct 14, 2019, at 7:14 PM, Ron Bonica  40juniper@dmarc.ietf.org> wrote:
> >>
> >> Jen,
> >>
> >> I am ready to request publication. But before we do that, we need a
> document shepherd.
> >>
> >> Eric,
> >>
> >> Was there anyone who was close to the draft, but not a co-author. We
> can victimteer that person.
> >>
> >> Ron
> >>
> >>
> >>
> >> Juniper Business Use Only
> >>
> >> -Original Message-
> >> From: Eric Vyncke (evyncke) 
> >> Sent: Saturday, October 12, 2019 3:41 AM
> >> To: opsec@ietf.org
> >> Cc: Jen Linkova ; Ron Bonica 
> >> Subject: Re: [OPSEC] I-D Action: draft-ietf-opsec-v6-20.txt
> >>
> >> As you will notice in
> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-opsec-v6-20__;!8WoA6RjC81c!R2vH-_v3NugiwIfTcXccEC89zGAXYR4rIB7oMxgV_5Tl11Z9jXZgMMuVCfC0QrYg$
> this latest revision addresses a suggestion by Gyan Mishra issued during
> the Working Group Last Call. Other changes are mainly replacing the
> normative "MUST" and "SHOULD" as it is an informational document (so it is
> now "must" and "should") + removing an unused informational reference.
> >>
> >> Jen and Ron, as the authors have addressed all comments received during
> the WGLC (actually by only one reviewer) and the extensive review by Jen,
> may I kindly request publication of this document?
> >>
> >> Thank  you all
> >>
> >> -éric -merike - kk -enno
> >>
> >>
> >> On 12/10/2019, 09:34, "OPSEC on behalf of internet-dra...@ietf.org" <
> opsec-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote:
> >>
> >>
> >>   A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >>   This draft is a work item of the Operational Security Capabilities
> for IP Network Infrastructure WG of the IETF.
> >>
> >>   Title   : Operational Security Considerations for
> IPv6 Networks
> >>   Authors : Eric Vyncke
> >> Kiran K. Chittimaneni
> >> Merike Kaeo
> >> Enno Rey
> >>   Filename: draft-ietf-opsec-v6-20.txt
> >>   Pages   : 52
> >>   Date: 2019-10-12
> >>
> >>   Abstract:
> >>  Knowledge and experience on how to operate IPv4 securely is
> >>  available: whether it is the Internet or an enterprise internal
> >>  network.  However, IPv6 presents some new security challenges.  RFC
> >>  4942 describes the security issues in the protocol but network
> >>  managers also need a more practical, operations-minded document to
> >>  enumerate advantages and/or disadvantages of certain choices.
> >>
> >>  This document analyzes the operational security issues in several
> >>  places of a network (enterprises, service providers and residential
> >>  users) and proposes technical and procedural mitigations
> techniques.
> >>  Some very specific places of a network such as the Internet of
> Things
> >>  are not discussed in this document.
> >>
> >>
> >>   The IETF datatracker status page for this draft is:
> >>
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-opsec-v6/__;!8WoA6RjC81c!R2vH-_v3NugiwIfTcXccEC89zGAXYR4rIB7oMxgV_5Tl11Z9jXZgMMuVCVgtmnGd$
> >>
> >>   There are also htmlized versions available at:
> >>
> https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-opsec-v

[OPSEC] Stepping down as OPSEC co-chair

[KK Chittimaneni]

Hi All,

Due to some personal reasons, I will be stepping down as OPSEC co-chair.

I’d like to thank everyone for the opportunity to have served as one
of your co-chairs. I have had a great time doing this, and think that
we've made some good progress. I leave the WG in the capable hands
of Gunter.

Once again, thank you all for making this a fun and interesting working group.

Regards,
KK

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

[OPSEC] OPSEC meeting at IETF 91 canceled

[KK Chittimaneni]

Dear OPSEC WG,

(Sorry, this email was supposed to go out last week, but sat in my
drafts folder.)

The chairs have been watching the activity on the OPSEC WG mailing
list and concluded that there are no open topics on the list that seem
to be problematic in nature to the extent that a 1:1 discussion at
IETF 91 is justified. As a direct result, we have requested the ADs to
cancel the OPSEC slot at the IETF 91 meeting.

We encourage the working group to continue discussing drafts on the
mailing list.

Kind Regards,
KK and Gunter

___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

[OPSEC] OPSEC IETF 90 - Call for Agenda Items

[KK Chittimaneni]

Dear All,

If you have a draft you would like to discuss during IETF 90, please send
your request for agenda time to the opsec chairs. Please include in the
request, the title and file name of the draft, the speaker's name, and how
much time you would need. We have one hour allocated to our session.

We will prioritize drafts that are WG items, drafts that have been actively
discussed on the list, and other individual submissions in that order.

Regards,
KK, Gunter
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

Re: [OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

[KK Chittimaneni]

Dear Opsec WG,

The co-chairs assessed the discussion on the list and now feel that there
was sufficient review to move this document forward.

Thanks,
KK (as Opsec WG co-chair)




On Sat, May 10, 2014 at 8:12 PM, KK Chittimaneni 
wrote:

> Dear Opsec WG,
>
> The WGLC for this draft technically ended last month with just one
> response received. Not enough to move forward.
>
> The co-chairs chatted about this and noted that there was a lot more
> support for this doc during earlier stages. Given that, we'd like to give
> the WG a bit more time to review this and extend the LC to the 24th of May.
> Ideally, we'd like to get at least two volunteers who could do a thorough
> review of this doc and post their comments to the list.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/
>
> <https://datatracker.ietf.org/doc/draft-ietf-opsec-ip-options-filtering/>
> Please read it now and report to the list whether you support publication
> or not. Insufficient responses will be taken as an indication of lack of
> interest and we'll stop from proceeding further.
>
> Regards,
> KK (as Opsec WG co-chair)
>
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

[OPSEC] Progressing draft-ietf-opsec-dhcpv6-shield

[KK Chittimaneni]

Dear Opsec WG,

The WGLC for this draft technically ended last month with just one response
received. Not enough to move forward.

The co-chairs chatted about this and noted that there was a lot more
support for this doc during earlier stages. Given that, we'd like to give
the WG a bit more time to review this and extend the LC to the 24th of May.
Ideally, we'd like to get at least two volunteers who could do a thorough
review of this doc and post their comments to the list.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-opsec-dhcpv6-shield/


Please read it now and report to the list whether you support publication
or not. Insufficient responses will be taken as an indication of lack of
interest and we'll stop from proceeding further.

Regards,
KK (as Opsec WG co-chair)
___
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec