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

From: Satendra <[email-masked]>
Date: Mon, 18 Dec 2006 15:23:23 +0530

Hi Victor,

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.

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. 

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

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. 

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.

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

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

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."

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 ?

8) Section 3.1.1.5 bullet 4:
Need to specify that link3 is down.Also a mention that vendor B and
vendor D are advertising only relay application.

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

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. 

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.

Regards,
Satendra
Motorola

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

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 18 Dec 2006 09:48:54 -0500

Hi Satendra,

> bullets 2 and 4. But looks like RFC 4004 explicitly states app id 0 for

ok.

> one of them is advertising support for only relay app and no other app

ok.

> app in auth app id, acct app id & VSA.

is'nt this already covered ?

> 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.

> C). Connection is established with both peers.

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

> can't be 30 seconds with all configurations

ok.

> 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.

>    vendor B will initiate TLS handshake on vendor B initiated

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

> Does RFC suggests such a behavior ?

We can remove that sentence.

> Need to specify that link3 is down.

ok.

> Also a mention that vendor B and

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.

> Need to specify vendor A2 and vendor B1 should be relays.

same as above.

> 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.

> - they will locally consume this message, because there is no dest host

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

regards,
victor