[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: issues raised at VPN interoperability workshop
---
Tim Jenkins Newbridge Networks Corporation
tjenkins@timestep.com http://www.timestep.com
timj@newbridge.com http://www.newbridge.com
(613) 599-3610 x4304 Fax: (613) 599-3617
> -----Original Message-----
> From: Dan Harkins [mailto:dharkins@network-alchemy.com]
> Sent: January 18, 2000 5:38 PM
> To: ipsec@lists.tislabs.com
> Subject: issues raised at VPN interoperability workshop
>
...
>
> Commit Bit
>
> * Can you clear the commit bit during phase 2?
>
> Yes.
>
What does this mean?
Is this asking "Can the commit bit be set to 0 in quick mode?"
(This is normal operation, so I doubt this was the question.)
Is this asking "Can the commit bit be set to 0 in the third quick mode
message by the initiator if set in the second by the responder?"
(Probably not supposed to be. One vendor interpreted this as rejection of
the bit, another ignored it. Maybe this should be clarified as well.)
Additionally, there was talk about allowing the initiator of a quick mode
exchange to set the commit bit. I'd like to propose that this be explicitly
disallowed, and that it explicitly stated that only the responder of a quick
mode exchange may set the commit bit.
Reasons:
1) The benefit is minimal, if any.
2) It increases complexity.
Does anyone do this? Does anyone support this case as responder?
...
>
> * Rekeying is an issue. Phase 1 or phase 2 or both?
>
> Tim Jenkin's Rekeying Draft addresses these. If you're having rekeying
> problems refer to that draft (which will be a BCP RFC, I believe).
Just to re-iterate: I plan on submitting it as informational only.
When it was asked who implemented it, the number of hands shown was less
than I've been told about privately, BTW.
The most recent version is at
<http://search.ietf.org/internet-drafts/draft-jenkins-ipsec-rekeying-03.txt>
. It was submitted two weeks ago, but I didn't see the announcement posted
on the list. It contains significant changes in the phase 1 re-keying
section to try to capture the conclusions of the WG exchanges on that topic.
...
>
> * Nuke the authentication-only bit.
>
> The only purpose for this bit is for Key Recovery and a
> request was made
> to remove it from RFC2408. What does the WG think?
>
The Niels-Schneier paper makes a good case for removal of this as well.
Let's do it.
Follow-Ups: