Nsis_Imp March 2005

nsis_imp@informatik.uni-goettingen.de

4 participants
5 discussions

Re: [NSIS] Possible NSIS interim meeting
by Xiaoming Fu 23 Mar '05

23 Mar '05

Any suggestions for the following response? Shall we also claim we'd discuss implementation and state machine issues? (actually we have some internal discussions on how to update them and plan to do it in one or two weeks.) thanks Xiaoming -- I would love to join NSIS interim meeting and discuss these interested topics, but unfortunately this date is not available for me - will be attending Networking 2005. For your information, we recently released a QoS NSLP implementation (currently based on CASP as NTLP): http://user.informatik.uni-goettingen.de/~qos Best regards, Xiaoming john.loughney(a)nokia.com wrote: > Hi all, > > I'd like to gauge support for an interim meeting. One suggestion would be to meet after the > ITU-T Workshop on NGN in Collaboration with the IETF. This meeting, just announced on the > IETF Announce list, will be held on 1-2 May, 2005, Geneva, Switzerland. Since many > IETF folks will be in Geneva for this, I think it could be convinient to discuss NSIS > matters aftwards - please note that there will be QoS & Signaling related topics at > this meeting. So, the proposal would be to meet May 3rd & 4th somewhere in or around > Geneva. > > Please let me know if you would be interested in attending an NSIS interim meeting and > if the date / place would be acceptable. > > thanks, > John > > _______________________________________________ > nsis mailing list > nsis(a)ietf.org > https://www1.ietf.org/mailman/listinfo/nsis

1 0

Re: [Nsis_imp] Refresh Messages and Refresh Timeout
by Tseno Tsenov 17 Mar '05

17 Mar '05

Hi Bernd, Pls. find inline my comments. Original Message: Hi, I've got a question concerning an established Cmode-Connection: * The sender sends a Refresh-Msg to the Receiver and starts a timer in case it doesn't come back. Yes. * The Receiver replies to it and also starts a timer in case the replie doesen't come back. No. The Receiver sends Response_Dmode message back and Refreshes its Upstream MRS and restarts the UpstreamRefresh timer. I dont think that it needs confirmation for successful reception of its response message. * The sender stops the timer. The sender stops the AdjacencyResponse timer and restarts the DownstreamRefresh timer. Al these messages are sent in Dmode. What does the sender do now? Does it send a replie to the replie? Is this continous? What happens if no replie comes back? Connection-close and transition to IDLE? Or WR to setup a new MA? I think the Sender should restart the discovery procedure, if no response come. The old MA might be disconnected or kept depending on local policy settings and if it is being reused or not. Greetings, Tseno_ Bernd _______________________________________________ Nsis_imp mailing list Nsis_imp(a)informatik.uni-goettingen.de https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp -- Tseno V. Tsenov MSCE, Technical University of Munich cell: +49 177 5964625 e-mail: tseno.tsenov(a)mytum.de

1 0

Re: [Nsis_imp] State Machine: Interaction with state installation
by Bernd Schloer 17 Mar '05

17 Mar '05

> 1a. If the node is being paranoid about DoS attacks, the response to a query > message should make minimal impact on the state in the responder node. Do we have to worry about DoS attacks during the prototype implementation? This is an important issue, but right now fancy stuff from my point of view. > 1b. For less paranoid nodes, the scheme as in the FSM draft and diagrams > applies. Will anybody adopt the less paranoid scheme? The way in 1b seems to be the quickest. > The FSMs currently reflect case 1b and the use of the newly established MA > to send a Cmode CONFIRM. Supporting 1a and Dmode CONFIRMS will need some > changes (depending on what view is taken of the CONFIRM issue). Sending the CONFIRM msg over the newly established MA is the way we do it in the C++ implementation. Bernd

2 2

Re: [Nsis_imp] State Machine: Interaction with state installation
by Tseno Tsenov 04 Mar '05

04 Mar '05

Hi Elwyn, Pls. see inline. ----- Original Message ----- From: "Elwyn davies" <elwynd(a)dial.pipex.com> > Hi. > > Having got to the details of generating RESPONSE messages, I think we have > some problems to sort out. > > There are (at least) two separate issues: > 1. There are two separate ways (timings) in which MRS is established at the > responder node (the downstream end). > 1a. If the node is being paranoid about DoS attacks, the response to a query > message should make minimal impact on the state in the responder node. > Although this is not spelt out in detail in the draft, the implication is > that the RESPONSE message should be generated but nothing about it should be > recorded if this is possible. I presume that the intention would be to > generate a RESPONSE cookie which could be verified as having been generated > by the responding node, that it was generated recently and that it hasn't > been tampered with just on the basis of the cookie alone without needing any > independently stored specific state. In particular, we shouldn't start > timers or create a FSM. The only thing that we have to ensure is that the > node is ready to accept a connection when the upstream node initiates a MA > (if it is going to). This is presumably true even if there is an existing > MA?? The response should be sent in Dmode irrespective of whether there is > an existing MA if this scheme is adopted. If and when a confirm arrives > (see issue 2) we go straight to Established state and setup all the MRS. > The Confirm can be checked to verify that it contains a RESPONDER cookie > that this node generated recently without needing the specific state - hence > the cookie needs to be cryptographically generated based on local time, node > identification and a private secret, allowing it to be decoded on the basis > of the single private secret ... no exchange of this secret is needed. Yes. Full handshake should be completed in D_mode. > 1b. For less paranoid nodes, the scheme as in the FSM draft and diagrams > applies. Will anybody adopt the less paranoid scheme? > I think the draft states the possibility for even looser scheme for the responding node: Section 4.4.1 states that responding node could establish a routing state after receiving of Query message. > 2. There is some confusion (IMO) as regards whether the CONFIRM message is > sent in Dmode when there is a new MA being setup. In draft -05, section 5.1 > seems to imply that CONFIRMS are only sent on pre-existing MAs in Cmode, > whereas Section 4.4.1 says that the GIMPS-Confirm is the first message sent > over the new MA. It is not clear which of these ought to be right: Yes it is not clear.In the FSM draft and diagrams comfirm message of MA is always sent over this MA. Still in section 7.4. it is stated that a combination of two defences against DoF attacks is used: 1. Receiving of confirm message over a secure channel 2. Response cookie This might be interpreted as that Confirm message is sent over newly established MA? >In fact > for case 1a above to work, the CONFIRM message has to be carrying the > querying nodes NAO which will only happen in Dmode. This is because in case > 1a, the querying node's NAO from the query message is not stored. This > could of course be solved alternatively by including the query node's NAO in > all CONFIRM messages. Since the MA, from which the CONFIRM message is received, is associated with a NAO of the quering node, there is no need to include the NAO in the confirm again. Isn't this the reason for which NAO is intentionaly removed from C_mode response and confirm messages.?/ section 4.4.2/ Greetings, Tseno_ > On the other hand, it will be much easier to tie up > the new MA's downstream end with the relevant MRS if the CONFIRM message > emerges from the new connection. If the CONFIRM message arrives separately > in Dmode, the responder node has to link the newly created (but quiescent) > connection (TCP socket) with the relevant MA state and the correct MRI. > This involves complex inspection of the peer address for the connection > etc., and it might not be so easy with other sorts of connection. > > The FSMs currently reflect case 1b and the use of the newly established MA > to send a Cmode CONFIRM. Supporting 1a and Dmode CONFIRMS will need some > changes (depending on what view is taken of the CONFIRM issue). > > Comments? > > Regards, > Elwyn > > _______________________________________________ > Nsis_imp mailing list > Nsis_imp(a)informatik.uni-goettingen.de > https://user.informatik.uni-goettingen.de/mailman/listinfo/nsis_imp >

2 1

web page recent changes
by Bernd Schloer 04 Mar '05

04 Mar '05

Also this mail might be lost: Hi list, please note the button 'recent changes' http://cleo-project.org/browse/recent_changes.html on cleo-project.org. This is a good entry to the web page as you see here what's going on and where progress was made. bye, Bernd

6 19

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Nsis_Imp March 2005