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

RE: draft-ietf-ipsec-ciph-aes-ctr-00.txt



Perhaps I'm overlooking something obvious here, but

The FEC has to be external to ESP for it to prevent authentication failure
at the ESP level. But I'm unaware of any provision within IP for FECs. Where
would one apply such an FEC in the protocol stack at the transmitting ESP
host/gateway that will make it through to the recipient ESP host/gateway?

> ----------
> From: 	Steven M. Bellovin[SMTP:smb@research.att.com]
> Sent: 	Friday, August 23, 2002 8:21 AM
> To: 	Waterhouse, Richard
> Cc: 	ipsec@lists.tislabs.com
> Subject: 	Re: draft-ietf-ipsec-ciph-aes-ctr-00.txt
> 
> In message
> <2575327B6755D211A0E100805F9FF9540E3455B4@ndhmex02.ndhm.gsc.gte.com>
> , "Waterhouse, Richard" writes:
> >> 
> >	>>> There is another application area that can benefit from CTR
> >mode. CTR doesn't do error extension. If you are working in a noisy
> >environment, have an application that can tolerate errors (but still
> don't
> >want a bit error to multiply), need confidentiality but can do without
> >authentication (e.g., you assure through other means that the plaintext
> is
> >inaccessible), CTR would be an appropriate choice. (Yes I know this
> violates
> >a MUST in the current draft, but that MUST leaves the developer without a
> >mode appropriate for use in noisy environments.)
> >
> >
> The proper solution in that sort of environment is forward error 
> correction.
> 
> 		--Steve Bellovin, http://www.research.att.com/~smb (me)
> 		http://www.wilyhacker.com ("Firewalls" book)
> 
>