March 2012 - Nsi-wg - lists.ogf.org

Issue 56 in ogf-nsi-project: Overloaded usage of 'Provisioned' state
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Status: Accepted Owner: tkudoh...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-1.1 FixedInVersion-2.0 New issue 56 by guy.robe...(a)gmail.com: Overloaded usage of 'Provisioned' state http://code.google.com/p/ogf-nsi-project/issues/detail?id=56 Description of Issue: In the state machine defined in NSI v1.1, the 'Provisioned' state is overloaded. Two meanings are associated with this state: 1. All child NSAs have acknowledged receipt of the provision command 2. All child NSAs have confirmed provisioning complete Discussion of Issue: Should we refine the state-machine to disambiguate these two different understandings of 'Provisioned'. A proposal has been made to add a new message 'Connection-State up'. Resolution of Issue:

1 1

Re: [Nsi-wg] Issue 32 in ogf-nsi-project: Interface version discovery
by ogf-nsi-project＠googlecode.com 16 Sep '12

16 Sep '12

Comment #3 on issue 32 by guy.robe...(a)gmail.com: Interface version discovery http://code.google.com/p/ogf-nsi-project/issues/detail?id=32 John M. has some ideas ... John to write-up a proposal.

1 2

Re: [Nsi-wg] Issue 24 in ogf-nsi-project: ServiceException needs further details
by ogf-nsi-project＠googlecode.com 16 Sep '12

16 Sep '12

Comment #6 on issue 24 by imo...(a)gmail.com: ServiceException needs further details http://code.google.com/p/ogf-nsi-project/issues/detail?id=24 Discussion on the Wed call 1. rename messageId to errorId 2. Appendix captures a list of errorId values and their meanings 3. errorId and text are both fields that are included by the entity Inder

1 3

Re: [Nsi-wg] Issue 39 in ogf-nsi-project: STP syntax
by ogf-nsi-project＠googlecode.com 16 Sep '12

16 Sep '12

Comment #2 on issue 39 by jmacau...(a)gmail.com: STP syntax http://code.google.com/p/ogf-nsi-project/issues/detail?id=39 I am confused by this agreement. An STP is defined as a OGF URN that is composed of the NSnetwork and localId already. Is this asking me to break out the STP into two discrete elements?

1 4

Full paper on NSI for TNC12 conference
by Radek Krzywania 02 Apr '12

02 Apr '12

Dear all, The deadline for TNC12 full paper is 16 April, so we don't have too much time (as usual). In the attachment I've placed a drafted template for this article, based on TERENA template. I would like to follow below schema: - ask yourself if you want to contribute to the paper :) - deadline ASAP - Browse attached ToC and see what and where you can contribute, please update ToC if you feel there is something missing and you may fill it - deadline - Wed 28.03 (we can finalize that via email on during NSI call) - People will be assigned to particular sections based on expressed interest - Thu 28.03 - Drafted contributions delivered - Fri 06.04 - Finalization on the paper - by Fri 13.04 - Paper submission - Mon 16.04 Comments are more than welcome. I'll take care of merging contributions and take care of formatting and versioning. I suppose we could use NSI forge to place docs in one place. Best regards Radek ________________________________________________________________________ Radoslaw Krzywania Network Research and Development Poznan Supercomputing and radek.krzywania(a)man.poznan.pl Networking Center +48 61 850 25 26 http://www.man.poznan.pl ________________________________________________________________________

11 20

Tomorrow's NSI conf call
by Guy Roberts 27 Mar '12

27 Mar '12

Hi all, The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 BST, 16:00 CEST, 23:00 JST *** note the new summer times**** 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: NSI v2.0 functionality and open issues Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

Securit infrastructure using TLS
by Henrik Thostrup Jensen 23 Mar '12

23 Mar '12

Hi So the "alternative" suggestion for a security infrastructure using TLS and X.509 infrastructure. Note: TLS is evolution/replacement of SSL. Requirements: - Peer authentication - Confidentiality - Message integrity - Replay protection At least we agree on those :-). TLS supports all of these, and have done it for more than 10 years. In the common setup only the server (defined as the one not initiating the connection) is authenticated. Typically (for HTTP applications) clients are then authenticated via username/password. However TLS supports authenticating clients via certificates just fine. This enforced by requiring clients to present a certificate in the service-side security context. There was an argument about TLS not providing end-to-end message integrity. That is simply not true. While it is possible to put TLS in a configuration with a reverse proxy and defining end in a certain way, one can make a strawmans argument about this. TLS is what is used when punching in your credit card numbers over the Internet or accessing your web-mail in secure fashion. It is good enough for NSI :-). Performance-wise setting up a TLS connection and creation a signed+encrypted message are roughly the same (involves the same amount prime number juggling). If using persistent connections TLS will use a negotiated secret shared key for encrypting the session, which is significantly cheaper than pure RSA, causing TLS to win hands-down. I don't think this will be an issue though (AFAIK it can also be solved by using WS-SecureConvensation, but that wasn't what was suggested). For completeness WS-Security comes much more unassembled than TLS. One has too choose signing and/or encryption along with what to actually do this on. Arguably WS-Security is a lot more flexible and allows stuff like passing on signed messages for repudiation, we don't have that in our requirement, and it doesn't fit very well into what we've outlined as a trust/peer network (we don't require all NSAs to thrust the certificate provider of all other NSAs and do message breakout). Now, both TLS and WS-Security can provide a solution which can solve our requirements. TLS however is much widespread both in usage and implementations as it is the de-facto standard for providing secure communication for the HTTP protocol. TLS is supported in virtually all major programming languages, either through native implementations or bindings to OpenSSL or GnuTLS. It is also protocol independent meaning that we can use the same security infrastructure for a client REST protocol. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

1 0

NSI v2.0 minutes
by Guy Roberts 22 Mar '12

22 Mar '12

Please find attached a list of features and functions to be included in NSI v2.0 as agreed in Oxford and associated action points. Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

Propposal for hierarchical error codes
by Henrik Thostrup Jensen 22 Mar '12

22 Mar '12

Hi everyone Following the discussion in Oxford, here is a more concrete proposal for hierarchical error codes. Some observations / statements: * An NSA can choose to present a single error code or a hiarchy of errors. * A requester might get an error code related to an unknown NSA. This is okay. How to handle this is undefined, and is - like most error handly - subject to policy. * We need a timeout error code for to indicate a timeout error. * We probably need a "downstream error" to indicate that the NSA is functioning correctly, but that an unrecoverable error happened downstream. It is also possible for an NSA to report a "regular" error code along with an error tree, in the case that an error happened both downstream and at the NSA itself. Message Structure: <ServiceExceptionType> <errorId> <text> <variables> <DownstreamExceptionListType> <DownStreamError> <NSA> <ServiceExceptionType> </DownStreamError> </DownstreamExceptionListType> </ServiceExceptionType> Comments? Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet

2 2

NSI-wg querying
by Yan Grange 22 Mar '12

22 Mar '12

Dear nsi-wg, As an employee of ASTRON, working for the NEXPReS project and the possibilities to implement the techniques developed for this project for the long-term archive of LOFAR, I am following the discussions on nsi-wg mailing list. Recently I have seen some discussion on the possible implementation of availability querying in the 2.0 version of the protocol. Since this is an option which is very interesting for our use case, I was wondering what the status was. As far as I understood, showing the availability would be a choice of the NSA and it is yet undecided whether or not this option will be used. I thank you for your time, Yours sincerely, Yan Grange -- Yan Grange Wetenschappelijk programmeur/Scientific programmer NEXPReS ASTRON het Nederlands instituut voor radioastronomie the Netherlands Institute for Radio Astronomy Radiosterrenwacht/Radio observatory Oude Hogeveensedijk 4 Paviljoen west kamer/room 16 Postbus 2, 7990 AA, Dwingeloo Nederland/The Netherlands Tel.: (+31) (0)521595796 Fax : (+31) (0)521595101 -- Yan Grange Wetenschappelijk programmeur/Scientific programmer NEXPReS ASTRON het Nederlands instituut voor radioastronomie the Netherlands Institute for Radio Astronomy Radiosterrenwacht/Radio observatory Oude Hogeveensedijk 4 Paviljoen west kamer/room 16 Postbus 2, 7990 AA, Dwingeloo Nederland/The Netherlands Tel.: (+31) (0)521595796 Fax : (+31) (0)521595101

1 0