Minutes of the Design Confcall for IPSP architecture

["Abdallah Rayhan" <arayhan@xxxxxxxxxxxxxxxxxx>]

Folks,

I would like to post to the list the minutes of the conf call 
we had last week to discuss the issues pertaining to the IPSP
architecture. Some of the issues are still to be sorted out
this may require another conf call before the Minneapolis
and probably a design meeting there as well to progress the
work. Feedback from the list on the presented issues
is greatly appreciated and thanks to those who participated.

Attendees: 
   Matt Condell, 
   Yaron Sheffer, 
   Fernando Cuervo, 
   Abdallah Rayhan 

When: Jan, 11, 2000 

Minutes:

1- Separating the policy requirements (e.g., tunneling topology) 
   from policy distribution (e.g., selectors and attributes)

There were some concerns about the difference between tunneling 
topology and low level policy (selectors and attributes).
Tunneling topology refers to policy of a higher level than 
selectors but eventually mapable to IPSec selectors. Tunneling 
topology encompasses several tunnels nested or not and each 
having different endpoints. Tunnels can be layered and cross 
several gateways and domains. Tunneling topology can be 
identified by two things:
     1- tunnel ends: IP addresses of source and destination
     2- security level: encrypted, authenticated, clear text
Tunnel ends refer where the start and end are which could be 
gateway/host. Security level refers to the security requirement 
of a tunnel or a set of tunnels. This would offer the service
of encrypted, authenticated or clear text tunnel which maps
to ESP, AH, or clear text, respectively. Note that I have not
included ports because they are of less importance to the
topology.

We agreed on the separation of requirements for services leading 
to topology and low level IPSec policy and that the low level
policy is the mechanism to implement the tunneling topology. 
The question is whether we aim for a more general approach.
The outcome of this is should to shape the discovery/resolution
models.

2- Confidentiality model for exchanged policy: 

Confidentiality was agreed as a requirement but ...
We discussed two levels of confidentiality.  There was agreement 
that providing confidentiality from gateways not involved in the 
resolution was a requirement, though there was not agreement that 
providing confidentiality from other gateways involved in the 
resolution was a requirement or even a good idea.

This relates also to the issue of how the need for confidentiality 
is established (this is related to the trust model: if there is a 
gateway in the path that is only trusted to provide a service 
it might be necessary for other gateways to hide information). 

In addition, since the protocol would most likely work with 
partial information (i.e., the path is discovered in a sequential 
manner) then the confidentiality may not be achieved in one pass, 
most certainly in two.

3- Trust model between gateways and/or policy domains 

When policy with respect to trust was discussed, it was argued
that it can be identified at two levels: "a priori" policy which 
states the trust relations for each entity and the level of
sensitivity of various objects, and the "rule set" that can be used 
directly to set up an IKE agreement. The former belongs to the high
level policy which is maintained by a policy management system.

Trust relationships allow the participating gateways in the discovered 
path to determine the services that a gateway can provide. It is not 
clear whether previous work exists in which this policies have been 
specified in the form of a schema. KeyNote was suggested but more 
insight into the problem is required. 

4- Nested domains operations of discovery and resolution 

This was a point of much debate: Should the outer gateway have 
any kind of access over the policy negotiated by the inner
gateway. The final requirement will depend on the following:

  a- Does the outer-most gateway have policies that allow other 
     (somewhere inside the domain) gateways to dictate the service 
     requirements and how explicit (i.e., how much info about the 
     service/traffic) are these service requirements. 

  b- Is it reasonable to assume that the outer-most gateway can be 
     reduced-to a transit gateway, this is only possible if supported 
     by the proper trust model.

5- Discovery in a non-global addressing environment (where IPSec 
   tunnels enable use of private addresses) 

It was agreed that this issue should be expressed in the requirement
possibly as: It should be possible to carry out the discovery/resolution 
mechanisms over IPSec based VPNs. This should take care into
considerations issues that may arise due to the presence of 
NAT and with/without the existence of VPN tunnels covering the cases 
when endpoints use either private or public addressing.

regards
Abdallah