[Nsi-wg] NSI service

Wed Sep 7 14:38:45 CDT 2011

Looks like mail is starting to come through the NSI-WG mailing list again.

The decision was made to use HTTP and BASIC authentication with a single fixed account.

John.

----- Original Message -----
> From: "John MacAuley" <john.macauley at surfnet.nl>
> To: "Atsuko Takefusa" <takefusa at acm.org>
> Cc: "NSI WG" <nsi-wg at ogf.org>
> Sent: Friday, September 2, 2011 11:54:36 AM
> Subject: Re: [Nsi-wg] NSI service
> 
> Can everyone one reply and let me know if they can do https or should
> we only do http?
> 
> I think we should use http basic authentication to secure the
> session.  Can everyone allocate a set of accounts on their system
> for each of the NSA and send the information to the associated NSA
> prime?
> 
> Thanks,
> John
> 
> Sent from my iPhone
> 
> On 2011-09-02, at 10:29 AM, Atsuko Takefusa <takefusa at acm.org> wrote:
> 
> > Hi Jerry, John, and all,
> > 
> > We will use "urn:ogf:..." values in <requester/providerNSA> and
> > <stpId>, won't we?
> > If so, why do we describe the "urn:ogf:..." values in the .owl
> > file?
> > 
> > 
> > And I have a question about security.
> > Which of the followings will we use at Rio?
> > 
> > #1 http + no authentication
> > #2 http + basic authentication (single user name & password)
> > #3 https + basic authentication (single user name & password)
> > #4 other
> > 
> > If #2 or #3, what are the user name and password?
> > 
> > Thanks,
> > 
> > Atsuko
> > 
> > 
> > 2011/9/2 Jerry Sobieski <jerry at nordu.net>:
> >> Ok good.   I agree with what you did...it makes sense to me.  And
> >> you and I
> >> had discussed the NSA topo object.   We just need to bring this to
> >> the group
> >> when we do a Rio post-mortem (:-).
> >> 
> >> I recall that we decided that the NSA and the Network were
> >> separately
> >> addressable entities - one was an active agent, and one just
> >> represented an
> >> administrative/infrastructure domain.  Each network has exactly
> >> one NSA, and
> >> each NSA manages exactly one network.   (This does not preclude
> >> things like
> >> federated structures in the future, but feds require some
> >> topological
> >> considerations that we have not broached yet.)
> >> 
> >> Thanks!
> >> Jerry
> >> 
> >> On 9/2/11 9:00 AM, John MacAuley wrote:
> >> 
> >> You are correct - copy and paste issue.  It should
> >> be urn:ogf:network:nsa:Martinique-DynamicKL.
> >> I can't remember if we decided to use the network to define the
> >> NSA, but in
> >> the topology we need to uniquely name the NSA and it can't
> >> conflict with the
> >> network name.  I made the leap of faith that we should then use
> >> this NSA
> >> name in the NSA fields.
> >> John.
> >> On 2011-09-02, at 8:49 AM, Jerry Sobieski wrote:
> >> 
> >> Hey John - question about the requesterNSA/providerNSA
> >> fields...see comment
> >> in line..
> >> 
> >> On 9/2/11 8:30 AM, John MacAuley wrote:
> >> 
> >> Looks like I have some explaining to do.  We forget that not
> >> everyone is
> >> participating in the NSI weekly meetings and the extra special OGF
> >> conference meetings.  Lucky for you, but unfortunately you miss
> >> the results
> >> of some of the discussions.  The is only one SOAP endpoint in the
> >> message
> >> and that is in the replyTo field.  We originally didn't have the
> >> replyTo
> >> field and the endpoints were in the requesterNSA and providerNSA
> >> fields,
> >> however, there was a push to make these field protocol
> >> independent.
> >> I wrote the new topology schema a couple of weeks ago so this is
> >> the first
> >> time a SOAP endpoint had shown up in the schema.  Mainly for
> >> discovering the
> >> ProviderNSA endpoint.  This will remove manual provisioning of the
> >> endpoint
> >> in each NSA. Howeve, now that we have this topology mechanism, we
> >> could
> >> expand it to hold the Requestor endpoint as well, removing the
> >> need for the
> >> replyTo field.
> >> 
> >> Here is what a request should look like based on all the
> >> agreements we have
> >> reached.  We need to make sure everyone follows this pattern or
> >> chaos will
> >> prevail :-)
> >> <soapenv:Envelope
> >> xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
> >> xmlns:int="http://schemas.ogf.org/nsi/2011/07/connection/interface"
> >> xmlns:typ="http://schemas.ogf.org/nsi/2011/07/connection/types"
> >> xmlns:urn="urn:oasis:names:tc:SAML:2.0:assertion"
> >> xmlns:xe="http://www.w3.org/2001/04/xmlenc#"
> >> xmlns:xd="http://www.w3.org/2000/09/xmldsig#">
> >>   <soapenv:Header/>
> >>   <soapenv:Body>
> >>      <int:reservationRequest>
> >>         <int:correlationId>urn:uuid:73d32a9d-fc68-4736-9c24-99abce1aaea3</int:correlationId>
> >>         <int:replyTo>http://orval.grid.aau.dk:7080/NSI/services/ConnectionService</int:replyTo>
> >>         <typ:reservation>
> >>            <requesterNSA>urn:ogf:network:nsa:Aruba-OpenNSA</requesterNSA>
> >>            <providerNSA>urn:ogf:network:NSnetwork:Martinique-DynamicKL</providerNSA>
> >> 
> >> Right here ^    Why do you specify an NSA URN in the requesterNSA
> >> field but
> >> specify a Network in the provider NSA field ??    These should
> >> both be NSA
> >> references.  Right?
> >> 
> >> Also, at SLC, we did not define an "NSA" URN...not that I recall.
> >>  Did we?
> >>    I think what you have will work nicely for now, but I don't
> >>    think it is
> >> in the spec. (?)   Therefore, we should put this on the near term
> >> dicussion
> >> list to get group consesnsus.  (we touched only on the Network
> >> <not equal>
> >> NSA issue, but not how that should be done or what the mapping
> >> supports,
> >> etc.)
> >> 
> >>           <reservation>
> >>               <globalReservationId>urn:ogf:network:service:Aruba:conn-560</globalReservationId>
> >> 
> >>               <description>OpenNSA Test Schedule #1</description>
> >>               <connectionId>urn:uuid:593d9816-0574-471d-b2a9-101e63a5d0f2</connectionId>
> >>               <serviceParameters>
> >>                  <schedule>
> >>                     <startTime>2011-10-15T21:32:52+01:00</startTime>
> >>                     <endTime>2011-10-15T22:32:52+01:00</endTime>
> >>                  </schedule>
> >>                  <bandwidth>
> >>                     <desired>100</desired>
> >>                  </bandwidth>
> >>               </serviceParameters>
> >>               <path>
> >>                  <directionality>Bidirectional</directionality>
> >>                  <sourceSTP>
> >>                     <stpId>urn:ogf:network:NSnetwork:Martinique:M1</stpId>
> >>                  </sourceSTP>
> >>                  <destSTP>
> >>                     <stpId>urn:ogf:network:NSnetwork:Martinique:M4</stpId>
> >>                  </destSTP>
> >>               </path>
> >>            </reservation>
> >>         </typ:reservation>
> >>      </int:reservationRequest>
> >>   </soapenv:Body>
> >> </soapenv:Envelope>
> >> 
> >> On 2011-09-02, at 5:45 AM, Henrik Thostrup Jensen wrote:
> >> 
> >> On Wed, 31 Aug 2011, John MacAuley wrote:
> >> 
> >> Yes you can combine them if you need to.  But I think the protocol
> >> will work
> >> without them combined. The csProviderEndpoint value tells the RA
> >> how to
> >> contact the PA for a network.  The RA fills in the replyTo field
> >> within the
> >> SOAP request to tell the PA how to respond with the confirmation,
> >> failed, or
> >> forcedEnd messages.
> >> 
> >> I combine the endpoints in OpenNSA, but as I interpret the
> >> protocol, this is
> >> not a requirement at all, and the protocol explicitely supports
> >> different
> >> endpoitns for this.
> >> 
> >> It is important to note, that the RA endpoint is only advertised
> >> through the
> >> replyTo field (AFAIK), and never in the topology and requester /
> >> provider
> >> fields.
> >> 
> >> Comments?
> >> 
> >> I find that there are way to many addressing schemes. Currently
> >> there is:
> >> 
> >> A. NSA provider endpoint advertisted through topology.
> >> B. NSA provider and requester endpoint specified in
> >> provider/requester
> >>   message fields.
> >> C. NSA requester endpoint specified in replyTo message field.
> >> 
> >> Which is simply to many IMHO.
> >> 
> >> I think the providerNSA and requesterNSA fields in the message
> >> could be
> >> removed entirely without problems (these fields smell alot like
> >> some low
> >> level protocol where security is not an issue - which is not the
> >> case for
> >> NSI at all).
> >> 
> >> I would also like to see the removal of the replyTo field, such
> >> that an NSA
> >> only has one contact point - the one advertised through the
> >> topology.
> >> 
> >> 
> >>    Best regards, Henrik
> >> 
> >> Henrik Thostrup Jensen <htj at ndgf.org>
> >> NORDUnet / Nordic Data Grid
> >> Facility._______________________________________________
> >> nsi-wg mailing list
> >> nsi-wg at ogf.org
> >> http://www.ogf.org/mailman/listinfo/nsi-wg
> >> 
> >> 
> >> _______________________________________________
> >> nsi-wg mailing list
> >> nsi-wg at ogf.org
> >> http://www.ogf.org/mailman/listinfo/nsi-wg
> >> 
> >> 
> >> _______________________________________________
> >> nsi-wg mailing list
> >> nsi-wg at ogf.org
> >> http://www.ogf.org/mailman/listinfo/nsi-wg
> >> 
> >> 
> > 
> > 
> > 
> > --
> > Atsuko Takefusa
> > Information Technology Research Institute, AIST
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/nsi-wg
> 