Subject: RE: [tcpm] [Repost] Review of the various TCP MACing proposals

From: "Sriram Viswanathan \(sriram_v\)" <[email-masked]>
Date: Tue, 11 Jul 2006 13:49:20 -0700

> 
> 
> Sriram Viswanathan (sriram_v) wrote:
> >  
> >>> A number of common issues come up here:
> >>>
> >>> - Use of key identifiers: One natural way to support key rollover
> >>>   is to incorporate a key (or association) identifier. This 
> >>>   allows the receiving party to determine which key was used
> >>>   to protect the received segment. It also provides a potential
> >>>   hook for external key management, e.g., via IKE.
> >> Where is that key ID in IPsec AH?
> >>
> >> There's only an SPI, the SPI indexes a database with the key ID, 
> >> which can change via a separate (IKE) protocol.
> >>
> >> In TCP-SA (simple-auth), we use the same principle:
> >> 	where SPI -> socket pair (IP pair, port pair)
> >>
> >>> - Trial Authentication: If multiple parallel keys are used for
> >>>   rollover and a key identifier is not used, then the receiver
> >>>   potentially needs to try all the available keys. Concerns
> >>>   have been raised about the potential for computation-based
> >>>   DoS in such systems.
> >> How is this handled in IPsec/IKE?
> > 
> > With IPSec, the unique SPI for each of the SA obviates the need for 
> > multiple checks.
> > With multiple parallel keys, or during the key transition 
> window (when 
> > both the current SA is within lifetime, and the new SA 
> established), 
> > the SPI is the unique identifier here.
> 
> I talked with Allison and Steve Bellovin this AM. The key 
> here is whether we care about dropped packets during the 
> transition. If not, we can save some bytes.
> 
> If so, we should add an ID-extender field. I say ID-extender 
> because the tuple would be:
> 	TCP socket pair, ID-extender
> 
> I.e., the ID-extender is NOT just a key ID; it's an ID within 
> this connection ID.

How would you specify this ID-extender? If this is marked explictly
on-the-wire, it brings in the need for the ID-extender to be symmetric
(or understood) at both endpoints. That would  conceptually be identical
to the usage of the keyid.

Thanks,
Sriram

> 
> > For TCP-SA, SPI interpretation as  socket pair(IP pair, port pair) 
> > will not be unique for the session. Restarting the session 
> to generate 
> > a different  tuple pair is not acceptable.
> 
> > To avoid multiple checks, TCP would have to carry the 
> equivalence of 
> > SPI
> > - keyid is one prime example.
> 
> As per above, we don't need a full SPI; the socket pair is 
> still the primary identifier.
> 
> Joe
> 
> 

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Joe Touch <[email-masked]>
Date: Tue, 11 Jul 2006 15:44:01 -0700

> to the usage of the keyid.

The tuple specifies all the parameters; when the tuple changes, ANY
parameter could change, i.e., key, algorithm, which header fields are
covered, etc.

See the I-D on this point; the LSAD contains the info, and the tuple is
the index to the LSAD. There is a utility to allow the tuple to change
within a connection - thus the ID-extender. There is no need to
associate that extender with any particular LSAD component.

Joe