Re: [OPSAWG] bof proposal review
> Description: With the dynamic nature of SDN/NFV networks, providers and > data center operators have to manage more dynamically the IP addressing > and provisioning of network nodes, Undoubtedly true. I would like to mention that this is clearly a target area for autonomic networking too; in fact one of the Anima use cases is a subset of this problem area. Not that I propose to derail the BOF with this comment, but the word "centralised" in one of the draft names suggests a specific approach and it may not be the only one. The model in https://tools.ietf.org/html/draft-ietf-anima-prefix-management is definitely not centralised (apart from policy). Regards Brian ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] bof proposal review
On 5 Oct 2016, at 12:45, joel jaeggli wrote: On 10/4/16 8:02 AM, Marc Blanchet wrote: Hello, the bof proposal below have been sent to OPS ADs (and INT ADs) and posted on the BOF wiki page. Benoît asked that this to be discussed here, since there is no public mailing list yet for this topic (we shall soon). So, I think we dicussed this is little bit back in march when the drafts were initially submitted. I think generally I'm postive on the idea of working on a yang model for data interchange between ipam systems or ipam systems and agents. Where I get into a little trouble is with the architecture, because it describes a couple of particular scenarios and my experience of carrier ipam systems doesn't really jive with that. In my experience, carrier ipam systems are part of a software stack associated with resource management of which address management is a component, not just ipam, and they tend as a result to be somewhat idioscratic. to my mind allocating resources for transition technologies is about the least interesting application I can imagine for such a tool and a very small portion of what it does, ours deals with v4 and v6 assignment simply as a matter of course. even on a somewhat smaller scale our ipam system has adopted json input and output so I think there is certainly a great arguement for standardizing the interchange format. in some ways, you are exactly stating the purpose of the bof: having other operators (than the original set) to chime in and provide their input and requirements. With more open forum, we shall be able to get a better set of common requirements and more focus and scope. Regards, Marc. thanks joel The primary purpose of the BOF is to extend the discussion to more operators (and other parties obviously) than the initial set to get an (hopefully) common set of requirements and identifying possible protocol work. It is a non- wg forming. Regards, Marc. === Name: IP Provisioning for SDN/NFV (ipprov) Description: With the dynamic nature of SDN/NFV networks, providers and data center operators have to manage more dynamically the IP addressing and provisioning of network nodes, including various network transition scenarios such as IPv4 as a service, where IP address and prefixes consumption are critical and require timely and dynamic reallocations. An initial set of providers have expressed requirements, but with different scopes (eg: only IP addressing and prefix management and delegation, vs larger provisioning scope). Some initial prototyping of solutions and field trial has started. The intent of the bof is to gather a common set of requirements from a larger set of operators and, if needed, possible protocol work milestones and scope. Status: not WG-forming Drafts: draft-xi-ps-centralized-address-management draft-sun-i2apm-address-pool-management-arch draft-sun-i2apm-address-pool-management-yang The responsible Area Director (AD): OPS or INT BoF Chairs (or the ADs as placeholders): Marc Blanchet and ... Proponents: Chongfeng Xie(CT), Ying Cheng(CU) Number of people expected to attend: 100 Length of session: 1.5 hour Conflicts to avoid (first priority): sdnrg, nfv, intarea, nfvrg, opsawg Conflicts to avoid (second priority): dtn, sunset4 ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] bof proposal review
On 10/4/16 8:02 AM, Marc Blanchet wrote: > Hello, > the bof proposal below have been sent to OPS ADs (and INT ADs) and > posted on the BOF wiki page. Benoît asked that this to be discussed > here, since there is no public mailing list yet for this topic (we > shall soon). So, I think we dicussed this is little bit back in march when the drafts were initially submitted. I think generally I'm postive on the idea of working on a yang model for data interchange between ipam systems or ipam systems and agents. Where I get into a little trouble is with the architecture, because it describes a couple of particular scenarios and my experience of carrier ipam systems doesn't really jive with that. In my experience, carrier ipam systems are part of a software stack associated with resource management of which address management is a component, not just ipam, and they tend as a result to be somewhat idioscratic. to my mind allocating resources for transition technologies is about the least interesting application I can imagine for such a tool and a very small portion of what it does, ours deals with v4 and v6 assignment simply as a matter of course. even on a somewhat smaller scale our ipam system has adopted json input and output so I think there is certainly a great arguement for standardizing the interchange format. thanks joel > > The primary purpose of the BOF is to extend the discussion to more > operators (and other parties obviously) than the initial set to get an > (hopefully) common set of requirements and identifying possible > protocol work. It is a non- wg forming. > > Regards, Marc. > > === > > Name: IP Provisioning for SDN/NFV (ipprov) > Description: With the dynamic nature of SDN/NFV networks, providers > and data center operators have to manage more dynamically the IP > addressing and provisioning of network nodes, including various > network transition scenarios such as IPv4 as a service, where IP > address and prefixes consumption are critical and require timely and > dynamic reallocations. An initial set of providers have expressed > requirements, but with different scopes (eg: only IP addressing and > prefix management and delegation, vs larger provisioning scope). Some > initial prototyping of solutions and field trial has started. The > intent of the bof is to gather a common set of requirements from a > larger set of operators and, if needed, possible protocol work > milestones and scope. > Status: not WG-forming > Drafts: draft-xi-ps-centralized-address-management > draft-sun-i2apm-address-pool-management-arch > draft-sun-i2apm-address-pool-management-yang > The responsible Area Director (AD): OPS or INT > BoF Chairs (or the ADs as placeholders): Marc Blanchet and ... > Proponents: Chongfeng Xie(CT), Ying Cheng(CU) > Number of people expected to attend: 100 > Length of session: 1.5 hour > Conflicts to avoid (first priority): sdnrg, nfv, intarea, nfvrg, opsawg > Conflicts to avoid (second priority): dtn, sunset4 > > ___ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg > signature.asc Description: OpenPGP digital signature ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] Start of WGLC for TACACS+ document.
Some comments. Mostly little nits and clarifications. The major points for me are related to security. The "Security Considerations" section is almost empty, and will certainly not pass a review from the security area. They will in all likelihood block publication until substantive comments have been added. -- 3.3. Single Connect Mode The packet header (see below) contains a flag to allow sessions to be multiplexed on a connection. * it would be good to name the flag here. If the server sets this flag in the first reply packet in response to the first packet from a client, this indicates its willingness to support single-connection over the current connection. The server may set this flag even if the client does not set it, but the client is under no obligation to honor it. * what happens if the client does not honour the flag? The flag is only relevant for the first two packets on a connection, to allow the client and server to establish single connection mode. The flag MUST be ignored after these two packets since the single- connect status of a connection, once established, must not be changed. The connection must instead be closed and a new connection opened, if required. Why would it be required to change the mode? It would be good to explain the use-cases, and why (or not) they make sense. TAC_PLUS_UNENCRYPTED_FLAG := 0x01 If this flag is set, then body encryption is not used. If this flag is cleared, the packet is encrypted. Unencrypted packets are intended for testing, and are not recommended for normal use. * it would be good to have a pointer to the security considerations, with a discussion of the implications. * Also, it's odd that a completely insecure mode is just "not recommended for normal use". I would suggest more panic-inducing phrasing. e.g. ."Unencrypted packets offer a complete compromise of all security related to the protocol and MUST NOT be used outside of a testing environment" TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 This flag is ussequernt, ed to allow a client and server to agree whether multiple sessions may be multiplexed onto a single connection. * I find the "agree" phrasing odd. I've mentioned before that the tone of the document is often philosophical. Perhaps saying instead "this flag signals whether the client and server are capable of performing session multiplexing" * i.e. the flag is a signal, not a capability for the systems to agree. session_id The Id for this TACACS+ session. The session id is to be selected randomly. This field does not change for the duration of the TACACS+ session. (If this value is not a cryptographically strong random number, it will compromise the protocol's security, see RFC 1750 * it would be good to update the paragraph to be more prescriptive. i.e. The Id for this TACACS+ session. The session id MUST be taken fro a cryptographically strong random number generation. If not, the protocol's security will be compromised. See RFC 1750 for further information ... length The total length of the packet body (not including the header). This value is in network byte order. Packets are never padded beyond this length. * Why is the text on "padding" there? The TACACS+ packets are sent over TCP, not UDP. So any "padding" would be outside of the scope of the current packet, and be seen by the other end as a subsequent, but invalid, TACACS+ packet. 3.5 ... - Unused fixed length fields SHOULD have values of zero. * what happens when they don't? I suggest adding text saying that the fields are ignored. - There will be no padding in any of the fields or at the end of a packet. * I wonder again what "padding" means here. 3.6. Encryption The body of packets may be encrypted. ... * Which is not a standard encryption method. Security people will complain here. I suggest (as before) using the term "obfuscated". With a note that for historical reasons, the flags / fields / etc. refer to TACACS+ "encryption". ... This document does not discuss the management and storage of those keys. ... * there should be some discussion in the Security Considerations section about this. Otherwise, this subject will be brought up in the security review. ... It is an implementation detail of the server and client, as to whether they will maintain only one key, or a different key for each client or server with which they communicate. For security reasons, the latter options MUST be available, but it is a site dependent decision as to whether the use of separate keys is appropriate. * those sentences seem to disagree with each other. It's an "implementation detail", but it MUST be supported. I suggest requiring the capability of per-server and per-client keys. ... The session id is used in network byte order. * nit: if the session
