Subject: [IPsec] poll: use of ADDITIONAL_TS_POSSIBLE

From: Scott C Moonen <[email-masked]>
Date: Mon, 18 Aug 2008 15:02:07 -0400

I'm curious to learn how existing IKEv2 implementations are making use of 
ADDITIONAL_TS_POSSIBLE.  I would greatly appreciate any responses to these 
questions:

1. Does your implementation support the full range of possible IKEv2 
traffic selector specifications, including the possibility of a single SA 
covering a disjoint set of selectors (e.g., TCP port 53 + UDP port 53)? If 
not, does your implementation choose to send the optional 
N(ADDITIONAL_TS_POSSIBLE) when applicable, or does it simply choose to 
narrow the traffic selectors without comment?

2. Does your implementation take any specific advantage of receiving 
N(ADDITIONAL_TS_POSSIBLE)?  For example, if your implementation proposes a 
TS that covers TCP port 53 and UDP port 53, but receives in response a TS 
that covers only TCP port 53 plus N(ADDITIONAL_TS_POSSIBLE), does your 
implementation log detailed diagnostic information for this case, or 
perhaps even automatically start a negotiation to protect UDP port 53 on a 
separate SA?

Since generation of N(ADDITIONAL_TS_POSSIBLE) is not required by RFC 4306, 
my desire here is to gauge how common or useful it is in practice.

Thanks in advance for your response,

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Aug 2008 15:01:35 +0300

> narrow the traffic selectors without comment?

We do support full range of possible IKEv2 traffic selectors, but do
not use ADDITIONAL_TS_POSSIBLE. There are some limitations of invalid
combinatins (i.e. we do not allow traffic selectors where source
selector is for UDP only and destination selector is TCP only), but
there is possibility to configure for example TCP port 53 and UDP port
53 when both ends are configure properly. 

> N(ADDITIONAL_TS_POSSIBLE)?

No.

> For example, if your implementation proposes a 

In our case we simply narrow the traffic selectors silently to
range that is acceptable the policy. In that case the initiator will
start new negotiation when packet is received that is outside the
negotiated traffic selectors, and as we always send the selectors from
data packet, the responder will correctly narrow down to that another
set. 

> my desire here is to gauge how common or useful it is in practice.

As the ADDITIONAL_TS_POSSIBLE is not mandatory the initiator cannot
really use it for anything. If it would be mandatory it could after
the negotiation where responder narrowed the traffic selectors check
if there is ADDITIONAL_TS_POSSIBLE possible and if not, it could mark
that policy rule so it will not cause additional triggers anymore. If
that ADDITIONAL_TS_POSSIBLE is there then it must keep the trigger
rules still there for those ranges which are not covered by the
negotiated SA, so packets to those ranges will cause new SAs to be
negotiated.

But as it is not mandatory, the initiator cannot trust the fact that
there is no ADDITIONAL_TS_POSSIBLE, thus it needs to keep the trigger
rules there for those ranges which are not covered by negotiated SAs
so effectively it simply does not do any special handling for the
ADDITIONAL_TS_POSSIBLE. The situation would be completely different if
the notification would be NO_ADDITIONAL_TS_POSSIBLE, then by receiving
it the initiator would know that it can remove the trigger rules for
that specific policy rule, as there is no point of trying to negotiate
anything outside the current negotiated SAs for that policy rule.

So currently I think ADDITIONAL_TS_POSSIBLE is really not useful in
any implementation. 
-- 
[email-masked]
_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yoav Nir <[email-masked]>
Date: Tue, 19 Aug 2008 15:33:23 +0300

Hi Scott

On Aug 18, 2008, at 10:02 PM, Scott C Moonen wrote:

>
> I'm curious to learn how existing IKEv2 implementations are making  
> use of ADDITIONAL_TS_POSSIBLE.  I would greatly appreciate any  
> responses to these questions:

I'm kind of curious about that too. There's the ADDITIONAL_TS_POSSIBLE  
notification, but lack of it is not a clear indication that this SA  
covers everything.

> traffic selector specifications, including the possibility of a  
> single SA covering a disjoint set of selectors (e.g., TCP port 53 +  
> UDP port 53)?  If not, does your implementation choose to send the  
> optional N(ADDITIONAL_TS_POSSIBLE) when applicable, or does it  
> simply choose to narrow the traffic selectors without comment?

We just narrow the traffic selectors without comment, based on the  
(what we assume to be) packet selectors. We don't send this notification

> N(ADDITIONAL_TS_POSSIBLE)?  For example, if your implementation  
> proposes a TS that covers TCP port 53 and UDP port 53, but receives  
> in response a TS that covers only TCP port 53 plus  
> N(ADDITIONAL_TS_POSSIBLE), does your implementation log detailed  
> diagnostic information for this case, or perhaps even automatically  
> start a negotiation to protect UDP port 53 on a separate SA?

No. We don't send it, and we ignore it if received. We send the packet  
selectors in our proposal, so if the peer is working correctly, the  
packet chosen was TCP 53.  If the need ever arises for UDP 53, then  
and only then we will negotiate an SA for UDP 53.  Note that all this  
is theory, because our UI only lets you configure subnets or ranges,  
and so our proposals are always for protocol 0 and all ports. It's  
still true for other subnets - we don't send ADDITIONAL_TS_POSSIBLE if  
there are other subnets that we haven't negotiated for.

> Since generation of N(ADDITIONAL_TS_POSSIBLE) is not required by RFC  
> 4306, my desire here is to gauge how common or useful it is in  
> practice.

IMO, not very useful