[OPSEC] opsec - Update to a Meeting Session Request for IETF 111
An update to a meeting session request has just been submitted by Jen Linkova, a Chair of the opsec working group. - Working Group Name: Operational Security Capabilities for IP Network Infrastructure Area Name: Operations and Management Area Session Requester: Jen Linkova Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: 6man v6ops spring lsr panrg People who must be present: Ron Bonica Warren "Ace" Kumari Jen Linkova Resources Requested: Special Requests: - ___ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec
Re: [OPSEC] Zaheduzzaman Sarker's No Objection on draft-ietf-opsec-v6-25: (with COMMENT)
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] Roman Danyliw's No Objection on draft-ietf-opsec-v6-26: (with COMMENT)
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] Alvaro Retana's No Objection on draft-ietf-opsec-v6-25: (with COMMENT)
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
