Hi Valery,

Thanks for your comments. Please see my replies inline [RSJ]

Kind Regards,
Raj


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of 
Valery Smyslov
Sent: Wednesday, October 23, 2013 7:08 PM
To: Rajeshwar Singh Jenwar (rsj); [email protected]
Subject: [IPsec] Some comments concerning 
draft-amjads-ipsecme-ikev2-data-channel-00.txt

Hi,

I have some comments concerning the draft.

1. As far as I understand, only one data channel can be created
    within one IKE SA. So, if application needs several different channels,
    it have to create several separate IKE SAs, performing authentication
    several times (probably involving human activity, if EAP is used).
    This is makes the whole architecture not so lightweight.

[RSJ]  Most of deployment use only single IPsec SA per peer, either
            They want to use security for all data for a peer/network or don't.
            The network for which we don't want security protection can be 
excluded using Access Control Lists (ACLs).
            So, in deployment where different application want to use IKEv2 
data channel, we can use same IKEv2 SA for same peer for different application. 
 
           We are working on how to multiplex different applications using 
single IKEv2 SA, currently, we are thinking of using  adding source and 
destination
           Port in IKEv2 data channel payload.   

2. Nothing is said abouth channel deletion. I presume it exists
    untill IKE SA is deleted, right?

[RSJ] Right. It is coupled with life of IKEv2 SA.

3. Could this IKE SA be used for other purposes,
    for example to create Child SAs as usual,
    or it must be explicitely dedicated to IKE Data channel?

[RSJ] Good Point. With IKEv2 data channel IKE_AUTH will not have IPsec payloads.
          But don't see any reason why this SA can't be used to create child 
SAs using CREATE_CHILD_SA exchange.

4. In Section 8.1 in description of Protocol ID:
    according to RFC5996 this field MUST be zero
    if SPI Size field is zero.

[RSJ] There is some confusion as per Sec 3.10, it is not very clear. 

Regards,
Valery Smyslov. 

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to