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

RE: Move TS to optional (RE: Don't remove TS from IKEv2)





> -----Original Message-----
> From: Jan Vilhuber [mailto:vilhuber@cisco.com]
> Sent: Tuesday, March 26, 2002 10:48 AM
> To: Sankar Ramamoorthi
> Cc: Andrew Krywaniuk; 'Dan Harkins'; 'IP Security List'
> Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2) 
> 
> 
> On Tue, 26 Mar 2002, sankar ramamoorthi wrote:
> 
> >
> >
> > > -----Original Message-----
> > > From: owner-ipsec@lists.tislabs.com
> > > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Jan Vilhuber
> > > Sent: Monday, March 25, 2002 7:30 PM
> > > To: Andrew Krywaniuk
> > > Cc: 'Dan Harkins'; 'IP Security List'
> > > Subject: RE: Move TS to optional (RE: Don't remove TS from IKEv2)
> > >
> > >
> > > Yes, I posted a link to it earlier.
> > >
> > > It's worth noting that during the presenation Pyda presented two
> > > different ways that the policy could get updated on both ends:
> > >
> > > - In IKE (which is what the draft talks about), but 
> changing IKE is BAD.
> > > - In some as yet unspecified IPSP protocol (and we again have the
> > >   problem that someone else pointed out: that doesn't exist yet :)
> > >
> > > So as each endpoint learns new policy (a new dynamic port), it
> > > *somehow* (i.e. via IKE or an external protocol) tells 
> the other end
> > > to add or remove policy from the SA.
> >
> > Are dynamic protocols a requirement for ikev2?
> > There have no comments to that regard.
> >
> 
> That's true. I think they are/should be. I'll ask Cheryl to add this
> to the requirements document.
> 
> It's a fact that these protocols exist, and based on the discussion so
> far, it seems a fact that people want to protect them. The SCTP draft
> that Angelos wrote also comes to mind.
> 
> 
> > Assuming that they are..
> >
> > One concern I have with the proposed approaches is the additional
> > latency between discovery of the dynamic information and 
> updating the
> > peer with the dynamic information. Using any of the 
> proposed mechanisms
> > (via IKE or external protocol), the latency may be unacceptably high
> > for some type of traffic.
> >
> 
> As I mentioned, a prior idea was to negotiate descriptors that say
> 'L2TP', rather than some port information. You'd have to provide an
> API to higher layers (say L2TP) to add and remove policy from a given
> SA. This assumes that L2TP *on both ends* can determine precisely the
> same additions and subtractions from the traffic selectors. Based on
> conversations I had with some l2tp folks, this seems to be the case
> for l2tp. Maybe this is true for ftp and h.323 as well. That way, no
> exchange (in IKE or IPSEC) needs to happen. It all happens via the
> higher layer protocol, which tells their corresponding IPsec stacks
> about it.
> 
> For gateways (i.e. where the IPsec stack is not on the same box as the
> ftp program, for example), this seems a bit harder, and NAT-like
> traffic inspection would need to happen. Yuck. But code for that
> exists already as well... So maybe this is feasible.

yes - that is how many gateways detect the dynamic information. However
using an external protocol to convey the information to peer will introduce
additional latency.

> 
> > Another alternative worth considering is to do policy change
> > inband to ipsec traffic. After all, if a secure a channel has
> > already been established with the peer, why not use the same channel
> > for updating the selector information?
> >
> 
> That would require changes to IPsec that I would really not even want
> to propose. The IPsec tunnel is for data traffic. Are you proposing
> yet another protocol which runs inside an IPsec tunnel? Why bother?
> You'd have the same latency. Maybe I'm misunderstanding.

Having an inband way (yes - that may require ipsec tunnel to
be accepting control traffic in addition to data traffic) allows the
possiblity of piggybacking control information along with data
within the ipsec tunnel. To me, that seems to be most efficient
way to indicate to the other side about the change in ipsec selectors.
The control channel can be put to other uses as well..

-- sankar --

> 
> jan
>  --
> Jan Vilhuber                                            
> vilhuber@cisco.com
> Cisco Systems, San Jose                                     
> (408) 527-0847
> 
> 
>