Subject: [Dime] Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt

From: Satendra <[email-masked]>
Date: Tue, 19 Dec 2006 11:26:36 +0530

Hi Victor,

Follow-up comments in line.

Regards,
Satendra

-------- Original Message --------
From: Victor Fajardo <[email-masked]>
To: Satendra <[email-masked]>
Cc: [email-masked], Tschofenig, Hannes
<[email-masked]>, [email-masked], G Nadaf
Liyaqatali-a21917 <[email-masked]>
Subject: Re: Comments on draft-fajardo-dime-interop-test-suite-02.txt
Date: Mon, 18 Dec 2006 09:48:54 -0500

Hi Satendra,

Thanks. Comments inline:
> We went through your test case draft, following are our observations. 
>
> 1) Application id in common messages:
> As the doubts about application id value in common messages have been
> clarified we can test for its compliance. Following text can be added to
> section 4.1.1.1.1. bullet 3 & 4, section 4.3.1.5 bullet 3 ,4. 
>  "Verify application id value in STR/STA message as that of the target
> application."
>
> Note: We would like to have the same comment applied to section 4.7.1
> bullets 2 and 4. But looks like RFC 4004 explicitly states app id 0 for
> STR/STA.
>   

ok.

> 2) Capabilities Negotiation for relay application:	
> Following test case can be added to section 3.1.1.1
>
> o Positive test for establishment of connection with test pairs of which
> one of them is advertising support for only relay app and no other app
> is in common. 
>   

ok.

> o Positive test for establishment of connection advertising the relay
> app in auth app id, acct app id & VSA.
>   

is'nt this already covered ?

Satendra>> Not really, test case does not mention in what avp's relay app id should be accepted.

> o Negative test case for TLS handshake failure. The connection is
> disconnected by both the peers. 
> Intentionally configure vendor A to send wrong certificate after
> Inband-Security-AVP with value 1 (TLS). TLS handshake should fail. 
>   

this maybe covered as well. my current thought is try not to be very 
detailed in the test cases so the document won't be so large that it 
becomes cumbersome to follow. in the specific case you mentioned above, 
there are probably multiple ways of making TLS handshake fail so it 
maybe best to leave it up to the participants to simulate a failure that 
is most convinient for them. Especially since we only have a few days to 
test.

Satendra>> Ok

> Optional test cases:
>  
> o Positive test for establishment of connection with inter and intra
> domain peers advertising support for use of TLS (for inter-domain) and
> IPSec (for intra-domain). Vendor A is an edge node which has peers
> intra-domain and inter-domain. Vendor A advertises inband Security AVP
> with TLS with the inter-domain peer (vendor B). Vendor A does not
> advertise inband security avp with TLS with the intra-domain peer(vendor
> C). Connection is established with both peers.
>   

Maybe this is a very specific deployment test instead of a general test 
case ?

Satendra>> If you feel that this is too specific we can leave the case out.

> 3) Positive test case can be for v6 connectivity to section 3.1.1
>
> 4) Section 3.1.1.3 para 1 "Determination must be made within 30 seconds
> of the event." The detection time will depend on watchdog timer and 
> can't be 30 seconds with all configurations
>   

ok.

> 5) Section 3.1.1.3: We can use the text in errata draft to specify the 
> peer behaviour when a DPR is received.
>   

Since the errata is still a draft ... I'm not sure if most existing 
implementation already follows it.

Satendra>> I believe the text in the errata draft is just a clarification 
           and the behavior can be tested.

> 6) Section 3.1.1.2: 
> a) The two test cases can be combined to one 
>    test case.
>    "Positive test for establishment of connection between 
>     two peers, one having higher identity than the other.  
>     Vendor A having a higher identity than vendor B.
>     Vendor A and vendor B initiate connection, verify that
>     vendor A initiated connected is closed at both the ends."
>
> b) One more test case can be added to verify the behaviour
>    of TLS in the election scenario.
>    "Positive test for establishment of connection with TLS between 
>    two peers,with election scenario, as mentioned above.
>    vendor B will initiate TLS handshake on vendor B initiated
>    transport connection."
>   

not sure what you mean. My understanding is TLS handshake is independent 
of election ... is there a specific need to integrate the test ?

Satendra>> The intent was to test who initiates the hand shake, anyway 
           this case can be left out.

> 7) Section 3.1.1.3 para 3:
> "Implementation should also attempt re-connection with lost peer before
> resetting the connection." 
> Does RFC suggests such a behavior ?
>   

We can remove that sentence.

> 8) Section 3.1.1.5 bullet 4:
> Need to specify that link3 is down.

ok.

> Also a mention that vendor B and
> vendor D are advertising only relay application.
>   

mmm... they don't have to be relays. what if other participants B and D 
wants to have a symmetric test similar to A and C.

> 9) Section 3.1.2:
> Need to specify vendor A2 and vendor B1 should be relays.
>   

same as above.

> 10) Section 3.1.2.1: "Positive test for multi-hop request forwarding.": 
> A2 should be relay, otherwise A1 will not send the request to it, since
> neither the dest host or the realm matches. Note that this message has
> dest host avp. Hence A1 cannot do realm routing.
> Also, B1 should also be a relay. 
>   

mmm... we have two(2) items here.

1. A2 does not necessarily need to be a relay. We can add either A2 and 
B1 are relay or has a realm route to B2. We need to give participants 
flexibility since they might want to test routing functionality that is 
interesting to them. Mandating one configuration over another may not be 
helpful.
2. Having a dest-host does not automatically preclude that your not 
going to do realm routing.

Satendra>> Why should peer A1 send out message to A2 when destination is realm B , 
           and A2 has not advertised itself as a relay ? 
           Does it mean that originator will send out message to any connected peer ?

> 11) Section 3.1.2.2: A2 and B1 should be relay in this case too.
> Otherwise, 
> - the message is routed to them because they support the app.
> - they will locally consume this message, because there is no dest host
> avp.
>   

Again, I advocate flexibility .... A2 and B1 can always have realms 
routes to B2 ....

regards,
victor

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

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 19 Dec 2006 10:43:13 -0500

Hi Satendra,

ok.

>            and the behavior can be tested.

... in this specific case, it may not be just a clarification since it 
pertains to re-connection behavior. since it's still a draft we may want 
to be careful on what we mandate.

>            this case can be left out.

I was thinking that instead of tying it to election, we can simply 
revive your original proposal on capabilities negotiation but in a more 
general tone. i.e. add:

"Negative test case for TLS handshake failure. In the case where the
negotiated Inband-Security involves subsequent TLS negotiation, participants
can simulate a TLS handshake failure (i.e. via invalid certificates, 
TLS/SSL
version mis-match etc) that must result in the peers being disconnected."

what do you think ?

>            and A2 has not advertised itself as a relay ? 

Because A2 can advertise that it supports the same application as B2 and 
has a realm route to B2 ... example is a proxy. We can add a sentence to 
that effect if it clarifies this.

regards,
victor