Hi Alper,
On Fri, Dec 18, 2009 at 5:19 AM, Alper Yegin wrote:
> Hi,
>
> I'm hoping by now it is understood that "childless IKE SA" is just a
> technical detail of what is really on the table. The proposal on the table
> is "designing a network access authentication protocol based on IKEv2".
> T
I'm not sure I'm going to buy that garage door opener if I have to wait for
dead peer detection before I can open or close it again :>).
Dave Wierbowski
From: Tero Kivinen
Hi,
I'm hoping by now it is understood that "childless IKE SA" is just a
technical detail of what is really on the table. The proposal on the table
is "designing a network access authentication protocol based on IKEv2".
That's what this WG and IETF should be discussing.
Having multiple solutions
> I'd like to suggest a slight variation: "MIPv6 MH Type values are
> treated as a single 16-bit integer port number, with Type in the
> most significant eight bits and the least significant eight bits
> set to zero."
Julien, thanks. I agree with your suggestion,
Scott Moonen (smoo...@us.ibm.co
Thanks for the text proposal, Scott.
I'd like to suggest a slight variation: "MIPv6 MH Type values are treated as a
single 16-bit integer port number, with Type in the most significant eight bits
and the least significant eight bits set to zero."
--julien
--
I suggest replacing the "Start Port" and "End Port" bullets in section
3.13.1 with the following:
o Start Port (2 octets) - Value specifying the smallest port number
allowed by this Traffic Selector. For protocols for which port is
undefined (including protocol 0), or if all port
Some comments inline...
>It does make more complexity for the middle boxes as they need to cope
>with both encrypted WESP and ESP-NULL WESP, thus they still cannot use
>just the WESP protocol number to indicate this packet is clear text.
>Now they also need to check the bit in the header, and if
Agreed.
Thanks,
Ken
>-Original Message-
>From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
>Of Jack Kohn
>Sent: Wednesday, December 16, 2009 3:33 PM
>To: Russ Housley
>Cc: ipsec@ietf.org; i...@ietf.org
>Subject: Re: [IPsec] DISCUSS: draft-ietf-ipsecme-traffic-visi
Hi Scott, Peter,
This text was kept simple deliberately, so we would not need to cover every
single case of different algorithm permutations.
The intention was as Peter indicates below "... "augmented" meant that the
bytes would be logically prepended to the existing ESP data before the ICV was
I think it is reasonable to expect that an IKEv2 bis implementation would
use an IF statement to control sending the new Notify types. If the minor
number was changed an implementation could check the minor version and send
the new notify types when the minor version was 1 and send the notify type
While re-reading the introductory paragraph in Section 2.9:
When an RFC4301-compliant IPsec subsystem receives an IP packet that
matches a "protect" selector in its Security Policy Database (SPD),
the subsystem protects that packet with IPsec. When no SA exists
yet, it is the task of
I think the criterion should be:
Would a reasonable and correct implementation need to have an IF
statement, e.g., if(minor_number == 1) ...
I do not not think the criterion should be whether bumping the number
breaks older implementations.
>From the discussion, leaving the number alone seems fi
Yaron Sheffer writes:
> Or else, we could remove the sentence "For example, it might
> indicate the ability to process a newly defined notification
> message."
That is example what changing minor number might mean. All current
conforming implementations already know how to process our newly
define
Yaron Sheffer writes:
> I agree with you regarding some of the proposals that have been
> floating around re: exposing bits and pieces of encrypted data.
I am really concerned about some of those late proposals for WESP
extensions, and if someone would have mentioned any of those earlier
when we w
David Wierbowski writes:
> Comment # 2:
>
> Section 1.7 (Differences Between RFC 4306 and This Document) states:
>
>The protocol described in this document retains the same major
>version number (2) and minor version number (0) as was used in RFC
>4306. That is, the version number is
Or else, we could remove the sentence "For example, it might indicate the
ability to process a newly defined notification message." I thinking bumping
the minor version number would be extremely risky. We know that everybody can
ignore unknown notifications. We don't know that everybody can deal
Paul Hoffman writes:
> This all seems like a compelling argument. However:
>
> >Because of that I suggest we do not add that text but instead add
> >sentense saying:
> >
> > As CHILD_SA_NOT_FOUND error refers to unknown SPI from the
> > responders point of view, it does not fill in the SPI field
17 matches
Mail list logo
