Subject: [IPsec] SA port binding

From: "Paul Moore" <[email-masked]>
Date: Thu, 1 Jan 2009 13:36:27 -0800

I see that the main WG is closed, hopefully this is the right place to pose these questions
 
I am trying to setup multi platform transport mode on a large scale and I am hitting several issues that come from different interpretations of the specs by the ipsec implementations. Main one is this:-

if an SA is established as the result of an SPD rule that specifies a port (ie on this subnet I want esp to port 21) does the SA belong exclusively to that port? In the above case this doesn't matter but if I have 2 rules
#1 on this subnet I want esp to port 21
#2 on this subnet I want esp to port 23
it does matter.
 
If I create an SA for rule #1 and then try to talk to port 23 on the same machine what should happen? There are 2 possibilities. I reuse the port 21 SA or I create a new SA for this flow. Either way works (assuming the same key rules etc) but both ends have got to agree. Windows and Solaris are in the 'this SA belongs to port 21' camp, and if a packet for 23 is sent using the 21 SA then it will be discarded. Linux is in the 'any SA will do' camp and tries to reuse the 21 SA. In fact in transport mode the Linux kernel is unaware of port numbers. You can tell Linux to create unique SAs (SA per flow)  but thats overkill as it creates a new SA for every flow (and I am not convinced that it interops correctly either). 

By majority voting Linux is the wrong one; but that is a bit simplistic (have not got to AIX and HP-UX yet). My vote (if I had one) is that the SA should not belong to the port, there is no reason for it to, and there are good reasons for it not to

So which is correct

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

---

From: Yoav Nir <[email-masked]>
Date: Fri, 2 Jan 2009 11:11:18 +0200

Hi Paul.

Windows and Solaris are correct not only because they are the  
majority. The question is what were the traffic selectors negotiated  
in IKE. If the IKE negotiation was about port 21, then the SA can only  
be used for port 21. If the SA was for any port then it can be used  
for both 21 and 23.

Our implementation never negotiates protocols and ports, only subnets  
(or ranges in IKEv2). We still have a firewall that may or may not  
drop traffic becuase of its rulebase, but conceptually, that firewall  
is behind the VPN endpoint.

On Jan 1, 2009, at 11:36 PM, Paul Moore wrote:

> I am trying to setup multi platform transport mode on a large scale  
> and I am hitting several issues that come from different  
> interpretations of the specs by the ipsec implementations. Main one  
> is this:-
>
>
> if an SA is established as the result of an SPD rule that specifies  
> a port (ie on this subnet I want esp to port 21) does the SA belong  
> exclusively to that port? In the above case this doesn't matter but  
> if I have 2 rules
> If I create an SA for rule #1 and then try to talk to port 23 on the  
> same machine what should happen? There are 2 possibilities. I reuse  
> the port 21 SA or I create a new SA for this flow. Either way works  
> (assuming the same key rules etc) but both ends have got to agree.  
> Windows and Solaris are in the 'this SA belongs to port 21' camp,  
> and if a packet for 23 is sent using the 21 SA then it will be  
> discarded. Linux is in the 'any SA will do' camp and tries to reuse  
> the 21 SA. In fact in transport mode the Linux kernel is unaware of  
> port numbers. You can tell Linux to create unique SAs (SA per flow)   
> but thats overkill as it creates a new SA for every flow (and I am  
> not convinced that it interops correctly either).
>
> By majority voting Linux is the wrong one; but that is a bit  
> simplistic (have not got to AIX and HP-UX yet). My vote (if I had  
> one) is that the SA should not belong to the port, there is no  
> reason for it to, and there are good reasons for it not to
>
> So which is correct
>

Email secured by Check Point
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Paul Moore" <[email-masked]>
Date: Mon, 5 Jan 2009 10:02:04 -0800

just to make sure I understand. 2409 says 

" The identities of the SAs negotiated in Quick Mode are implicitly
   assumed to be the IP addresses of the ISAKMP peers, without any
   implied constraints on the protocol or port numbers allowed, unless
   client identifiers are specified in Quick Mode."

So if the qm exchange has an IDcx with a port number in it then the resulting SA is only for that port. 
So in my case the IDcr sent by the initiator contains 21. And thus that SA is for port 21.
Does the response from the responder have to contain a port number?
Can I put a port number in even if the SPD entry doesn't specify a port. And vice versa; can I leave out the port number even though the SPD does specify a port

From: Yoav Nir 
Sent: Friday, January 02, 2009 1:11 AM
To: Paul Moore 
Cc: [email-masked] 
Subject: Re: [IPsec] SA port binding

Hi Paul. 

Windows and Solaris are correct not only because they are the majority. The question is what were the traffic selectors negotiated in IKE. If the IKE negotiation was about port 21, then the SA can only be used for port 21. If the SA was for any port then it can be used for both 21 and 23. 

Our implementation never negotiates protocols and ports, only subnets (or ranges in IKEv2). We still have a firewall that may or may not drop traffic becuase of its rulebase, but conceptually, that firewall is behind the VPN endpoint.

   

  So which is correct

--------------------------------------------------------------------------------

---

From: "Paul Moore" <[email-masked]>
Date: Mon, 5 Jan 2009 11:30:57 -0800

I can answer one of my questions. If I change racoon to not send the port number in the IDcr attribute then Windows refuses to set up the SA. 

From: Paul Moore 
Sent: Monday, January 05, 2009 10:02 AM
To: Yoav Nir 
Cc: [email-masked] 
Subject: Re: [IPsec] SA port binding

From: Yoav Nir 

Hi Paul. 

   

  So which is correct

---

From: Yoav Nir <[email-masked]>
Date: Tue, 6 Jan 2009 01:37:34 +0200

If we're talking IKEv1, then AFAICT the responder MUST send exactly  
the same selectors (or ID payloads in IKEv1 terminology) as the  
initiator sent.  There's no real "negotiation"

On Jan 5, 2009, at 8:02 PM, Paul Moore wrote:

> Can I put a port number in even if the SPD entry doesn’t specify a  
> port. And vice versa; can I leave out the port number even though  
> the SPD does specify a port
>
>
>
> From: Yoav Nir
> in IKE. If the IKE negotiation was about port 21, then the SA can  
> only be used for port 21. If the SA was for any port then it can be  
> used for both 21 and 23.
>
> Our implementation never negotiates protocols and ports, only  
> subnets (or ranges in IKEv2). We still have a firewall that may or  
> may not drop traffic becuase of its rulebase, but conceptually, that  
> firewall is behind the VPN endpoint.
>
>> If I create an SA for rule #1 and then try to talk to port 23 on  
>> the same machine what should happen? There are 2 possibilities. I  
>> reuse the port 21 SA or I create a new SA for this flow. Either way  
>> works (assuming the same key rules etc) but both ends have got to  
>> agree. Windows and Solaris are in the 'this SA belongs to port 21'  
>> camp, and if a packet for 23 is sent using the 21 SA then it will  
>> be discarded. Linux is in the 'any SA will do' camp and tries to  
>> reuse the 21 SA. In fact in transport mode the Linux kernel is  
>> unaware of port numbers. You can tell Linux to create unique SAs  
>> (SA per flow)  but thats overkill as it creates a new SA for every  
>> flow (and I am not convinced that it interops correctly either).
>>
> Scanned by Check Point Total Security Gateway.
>