Paul Hoffman writes:
> This appeared on the list over two weeks ago and it has received no
> comments since. This is supposed to be the WG's main work item,
> folks. 

My comments:

> 2.2.  Gateway-to-Gateway AD VPN Use Case
...
>    The spoke gateways can themselves come up and down, getting different
>    IP addresses in the process, making th static configuration
					 ^^
Typo.

> 3.2.  Star Topology
...
>    This solution however does not work when the spokes get dynamic IP
>    address which the "hub gateways" cannot be configured with.  

I think star topology works fine with dynamic IP addresses. You just
need to make sure that the spokes are the entities which brings up the
link, i.e. immediately when they boot up they put up the IPsec link
and keep it up all the time. There is other identities in the IPsec
world than IP-addresses...

I would remove the whole sentence.

>    bandwidth.  A single packet in the hub-and-spoke scenario can be
>    encrypted and decrypted three times.  It would be much preferable if

In the pure hub-and-spoke model I cannot really see more than two
times, one from the spoke to hub, and second time from the hub to
another spoke. If there is hub to hub links also then it is not pure
hub-and-spoke scenario anymore. I would replace the "three" with
"multiple". I myself really had to read the first paragraph of this
section again to notice that you talk there that this section says
there can be multiple gateways selected as hub gateways.

> 4.1.  Gateway and Endpoint Requirements
...
>    2.  Gateways and endpoints MUST allow IPsec Tunnels to be setup
>    without any configuration changes, even when peer addresses get
>    updated every time the device comes up.

This is unclear for me. Does that mean that anybody can connect to the
gateway and the gateway MUST allow IPsec Tunnels to be setup without
any configuration changes (like adding authentication credentials?). I
do not think so.

I think this needs to be clarified. Also endpoints do require
configuration changes before they can first time connect to the AD
VPN, for example you need to insert the credentials and most likely
also point at least one gateway for them to fetch rest of
configuration from them.

If this is just trying to say that already configured devices in the
AD VPN MUST be able to connect to any other configured device in the
AD VPN at any time, even when the IP addresses are not known
beforehand, then I think it should be said differently.

Anyways I am not sure what this is trying to say.

>    This implies that SPD
>    entries or other configuration based on peer IP address will need to
>    be automatically updated, avoided, or handled in some manner to avoid
>    a need to manually update policy whenever an address changes.

This is much more clear, and I think this most likely means that the
first paragraph was trying to say that already existing AD VPN members
should be able to connect other AD VPN members even when their
IP-addresses are not static.

Next question is how does the one member know to which address connect
to if also the destination member has changing IP address? And how to
punch holes to NATs that might be between them.

>    3.  Gateways MUST allow tunnel binding, such that applications like
>    Routing using the tunnels can work seamlessly without any updates to
>    the higher level application configuration i.e.  OSPF configuration.

I have no idea what this requirement means. What is "tunnel binding"?
Where does this requirement come? Which use case drives this?

>    4.  In a hub-and-spoke topology, spoke gateways and endpoints MUST
>    allow for direct communication with other spoke gateways and
>    endpoints.

Hmm... why are you listing here spokes and endpoints as separate
entries. In the terminology I understood spoke also includes
endpoints? 

>    5.  One spoke MUST NOT be able to impersonate another spoke.

If spoke does not imply endpoints, then we should say that this also
applies to the endpoints, i.e. One endpoint or spoke MUST NOT be able
to impersonate another spokes or endpoints.

What about hubs? Are they allowed to impersonate other hubs? I assume
yes, but then next question comes are hubs allowed to impersonate as a
spoke or endpoint? Is there any requirement that when endpoint makes
direct connection to other endpoint it knows that there cannot be any
other parties listening on the link? If there is such requirement then
also the hubs are not allowed to impersonate endpoints, but on the
other hand if we use CA infrastructure, then the CA can always issue
certificate allowing this kind of impersonation.

>    6.  Gateways SHOULD allow for easy handoff of sessions in case
>    endpoints are roaming, even if they cross policy boundaries.  This
>    means that TCP session breakage and packet loss should be avoided,
>    when possible.
> 
>    This requirement is driven by use case 2.1.  Today's endpoints are
>    mobile and transition often between different networks (from 4G to
>    WiFi and among various WiFi networks).

This cannot come from case 2.1, as that is endpoint to endpoint, so
there is no gateway at all there. I would expect this would come from
2.3 i.e. the endpoint to gateway use case.

Or does this mean gateways should allow handoff from the
endpoint-gateway-endpoint to direct endpoint-endpoint link without
breaking TCP sessions?

>    8.  Gateways and endpoints MUST be able to work when they are behind
>    NAT boxes.  However, it is especially difficult to handle cases where
>    gateways are behind NATs and where two endpoints are both behind
>    separate NATs.  In those cases, workarounds MAY be used such as port
>    forwarding by the NAT or detecting when two spokes are behind
>    uncooperative NATs and using a hub in that case.
> 
>    This requirement is driven by use cases 2.1 and 2.2.  Endpoints are
>    often behind NATs and gateways sometimes are.  IPsec should continue
>    to work seamlessly regardless, using AD VPN techniques whenever
>    possible and providing graceful fallback to hub and spoke techniques
>    as needed.

Does this also include discovery of the addresses? How about if we
have two endpoints talking to each other and one of the nat boxes is
restarted and one peers IP-address changes, and as the NATs are
restricted nats, which means they cannot connect to each other at all
after that without the help of the 3rd party. Also the 3rd party
cannot connect to either one of them, thus the recover must then start
from the endpoints so both of them connect to this 3rd party (hub) to
recover from the situation. 

>    9.  Changes such as establishing a new IPsec SA SHOULD be reportable
>    and manageable.  However, creating a MIB or other management
>    technique is not within scope for this effort.
> 
>    This requirement is driven by manageability concerns for all the use
>    cases, especially use case 2.2.  As IPsec networks become more
>    dynamic, management tools become more essential.

I would rule configuration MIB out of the scope, but I would actually
think it would be good idea to make reporting and statistics MIB. We
really need one in the IPsec, and this is effort I think we should
take here in ipsecme also for normal IPsec devices.

I am sure we are still missing some requirements, but thats my
comments for the existing requirements. I need to think bit more what
other requirements we might have.
-- 
kivinen@iki.fi