Subject: RE: [Tsvwg] Some other questions about the AddIP extension

From: [email-masked]
Date: Mon, 25 Feb 2002 14:48:03 +0200

> [email-masked] wrote:
> > 
> >         Debugging my implementation I'm thinking about 
> strange situations...
> > 
> >         What will happen if the peer tries to add an 
> address that is being used by another association within this 
> same endpoint (of course, both associations should be using 
> the same destination port as well)? Silently discard the 
> chunk (and maybe the whole datagram)?
> 
> 
> So are you saying
> 
> 
> Host 1                                         Host-2
> 
> IP-A                                          IP-Z
> IP-B                                          IP-Y
> IP-C                                          IP-X
> 
> (IP-A,     <--------------asoc 1-------------------> (IP-Z,IP-Z, port:5555)
>  IP-B,
>  port:4444)
> 
> (IP-C:port4444)<--------------asoc 2------------------->(IP-X:port:5555)
> 
> Then assoc 2 attempts to do
>          addip(IP-A)------------------------------>
> 

	Well, not exactly. If asoc 1 has "IP-X, IP-Z" then the answer is yes. Because (IP-A, 4444) <-> (IP-X, 5555) would be a valid address/port pair in both associations...

> > 
> >         Thinking about my previous mail... There is a 
> really weird case when the second ASCONF ACK might be 
> different. When the peer (an attacker?) tells us to add an 
> address that is being used by another association, but that 
> association deletes that address before we receive the second 
> ASCONF chunk... And there might be more situations (ok, 
> REALLY strange ones... :-)).
> 
> So you are also saying that the attacker has guessed both the
> sequence number and the V-Tag on the association?

	No. I was thinking about another case where simply re-parsing the ASCONF chunk is not enough to assure that the resulting ASCONF ACK would be the same. It would be like being in the situation shown in the graph above, and then the addip(IP-A) is resent but meanwhile, asoc 1 sent delete(IP-A). Thus, initially the addip(IP-A) was illegal (and my question continues, what should be done?), but upon receipt of the retransmitted ASCONF it would be a valid situation...

> > So this makes me think harder that either the last ASCONF 
> ACK chunk should be compulsorily kept in memory (in fact, I 
> think that this is what all of us are going to do), or it is 
> stated in the draft that simply re-parsing the ASCONF chunk 
> might not be the right thing to do... :-0
> 
> But that is an implementation decision Ivan.. You are 
> REQUIRED TO ANSWER
> the SAME.. How you do it is up to you but you MUST answer the same.
> 
> Please don't confuse requirements with implemention decisions..

	Ok, but then I think that having a note somewhere in C3 saying that simply reparsing the ASCONF chunk might not be enough to assure that we are producing the same ASCONF ACK as we originally did...

> It is like the SACK Gap-Acks.. I can think of NO easy way to
> list the Gap-Acks to my peer out of order.. but we do NOT make
> a requirement that they be in order since some future person
> may come up with something brilliant that makes this happen.
> 
> There is NO reason to dictate implementation in the spec only
> require what must be done..
> 
> > 
> >         What should we do if the peer deletes all the 
> active addresses (i.e., after the deletion we only have 
> inactive addresses)? Should we close the association? :-/ The 
> ASCONF chunk must have come from one of the inactive 
> addresses, so the card and the return path are working... 
> Maybe we should try with the inactive addresses until we 
> reach the Max.Association.Retrans... I guess this might be an 
> implementation specific issue...
> > 
> 
> Well this is an issue no matter if you have add-ip or not.. what does
> your implementation do if all the addresses go in-active?
> 
> Ours continues to attempt to both send and heartbeat on the
> in-active addresses until Max.association.retrans is reached...
> 
> Add-ip should not influence this...

	Ok!

	Thanks for your answer!

	BR Iván Arias Rodríguez

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg