[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Specification of tunnel/transport attribute in IKEv2



It wouldn't hurt to thing in terms of large scale deployments. Try to be 
in the shoes of the administrator that is taking care of a mid size ISP. 
The scenario could look like several VPNs per customer, hundreds of 
customers (hopefully), probably each customer using an independent box. 
I  don't mean that what it is being discussed is wrong, but I would like 
to bring this up.

If the complexity is in the protocol, vendors try to make it easier in 
their implementations. Some get it right some don't.

My 2c.
marc.

Markku Savela wrote:

>>From: Paul Hoffman / VPNC <paul.hoffman@vpnc.org>
>>    
>>
>
>  
>
>>- need some policy negotiation outside of IKE before packets start
>>to flow
>>    
>>
>
>Sort of, administrators of both sides have to agree to allow the
>packets to flow. Then, both sides modify their policies accordingly. I
>don't see any need for "policy negotiation protocol" between end
>hosts.
>
>I do see that sometimes a general IPSEC policy exchange format
>might be a useful thing. A policy described in this notation could be
>transferred to the users via different methods (email, http, etc).
>
>  
>
>>- need some policy announcement when bad packets are received 
>>("you're sending me packets that I have no intention of passing to 
>>the inside network")
>>    
>>
>
>Not policy announcement. Just optional notification from one IKE to
>another. This would alert the sender that there is "black hole".
>
>1) Sends encodes the packet with SA(s)
>
>2) Receiver successfully decodes the packet with SA(s)
>
>3) Receiver checks that the uncovered plain packet matches the policy
>   (as described in RFC-2401).
>
>4) If packet does not match the policy, then there is a policy
>   mismatch and a potential black hole (or cracking attempt). A
>   notification can be sent to all key management servers. This notice
>   could contain selector data from the packet and SA(s). IKE (or any
>   other key manager) receive this message and from it can deduce
>   whether the problem SA's are negotiated by it. If so, it can use
>   the phase 1 session to pass the appropriate information to the
>   other end.
>
>5) Upon receiving the notification, the sender knows that it's packets
>   are not accepted. Solving the problem requires human
>   intervention.
>
>IKE can do above without any knowledge about the actual policy.
>
>This way even handles the black holes, that current IKE does not
>detect: sender sends packets using wrong SA (like, negotiate SA for
>telnet traffic, but use FTP over it).
>
>  
>

-- 
Your favorite stores, helpful shopping tools and great gift ideas. 
Experience the convenience of buying online with Shop@Netscape! 
http://shopnow.netscape.com/