At 10:40 AM +0530 11/23/10, Anil Maguluri wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_903D13EA90218E43BA0881BC8B569C7D0F8B8FB7B1BLRINMSMBX01b_"
Hi All,
Please clarify me the below query.
è When AH Header Length becomes zero (in which scenario)?
è
At 11:05 PM +0200 2/11/11, Yaron Sheffer wrote:
Hi Steve,
[Cross-posted to ipsecme]
I have always wondered about these sequence numbers, and the concept
of anti-replay in IPsec.
- IPsec is architecturally a "plug-in replacement" for IP. And IP
allows for arbitrary packet deletion, duplicati
At 11:24 AM +0530 8/29/11, Naveen B N (nbn) wrote:
Hi Scott,
Even with the Pre-shared secret, the protocol can't keep up the
property of " perfect Forward secrecy".
I have assumed the both the server and client use pre-shared secret,
same below methods applies to Certificate based
Authenticati
At 10:53 AM -0400 10/19/11, Danny Mayer wrote:
On 10/18/2011 12:42 PM, Kevin Gross wrote:
It does seem reasonable to consider modeling encryption and decryption
in as part of network latency. As long as delays introduced are the same
each direction, the sync protocols will naturally subtract
At 8:15 PM -0600 10/19/11, Kevin Gross wrote:
We don't need decrypt and encrypt to take the same amount of time.
We need encrypt+decrypt from master to slave to take the same time
as encrypt+decrypt from slave to master.
That further reduces the likely variance that is algorithm or mode specif
In most contexts, there is no real benefit to using two SAs (AH +
ESP) as you describe. I agree that, in almost every case, just using
ESP will suffice. Using ESP in tunnel mode is certainly good enough,
and less expensive than 2 SAs.
Steve
___
IPse
At 1:56 AM -0500 11/15/11, Steven Bellovin wrote:
On Nov 13, 2011, at 4:30 PM, Vilhelm Jutvik wrote:
> De...
The notion of discarding AH entirely has been discussed for many years.
I've long been in favor of it, though I can't find a copy of anything old I
had posted in my mail archives at the
At 4:54 AM +0530 11/23/11, Jack Kohn wrote:
As per RFC 4301 implementing AH is a MAY and ESP a MUST. Given that
most of what is achieved by AH can be easily achieved by ESP-NULL, is
there a possibility that AH may get deprecated in the future. Should
new protocols or mechanisms be defined in IETF
At 2:40 PM +0800 1/20/12, zong.zaif...@zte.com.cn wrote:
Hi Folks:
There is a new draft available that some of you may be interested
in looking at.
The draft is available via the following link:
http://www.ietf.org/id/draft-zong-ipsecme-ikev2-cpext4femto-00.txt
Please send your comments to the
At 9:31 PM -0800 1/26/12, t...@zteusa.com wrote:
...
Tricci > Fully agree with you that, we need to make a proposal to be
consistent with IETF standards. In addition, I am also hoping you
would agree that, as the solution is proposed to fix a generic issue
for Femto network, we need to also
At 4:39 PM +0800 1/29/12, zong.zaif...@zte.com.cn wrote:
Hi Stephen, Tricci:
Sorry that I didn't respond this email on time due to the chinese
spring festival. I would like to thank Stephen first for reviewing
the draft and giving me your suggestions.
no problem. Happy New Year.
From readin
At 1:12 AM + 4/3/12, Xiangyang zhang wrote:
A new version of I-D, draft-zhang-ipsecme-multi-path-ipsec-00.txt
has been successfully submitted by Xiangyang Zhang and posted to the
IETF repository.
Filename:draft-zhang-ipsecme-multi-path-ipsec
Revision:00
Title:Multiple Path
At 4:44 AM + 4/6/12, Xiangyang zhang wrote:
Steve,
Your understanding is partially right. Only that anti-replay window
could possibly be bigger if two paths go along the different routes.
If two paths go along the same route, it is no difference from the
traditional single SA. But the a
At 4:50 PM + 4/6/12, Xiangyang zhang wrote:
Stephen,
You understand this method very well. The disadvantage is the
possible severity of out of order delivery. Even with single SA, it
can also cause the out of order problem. As for re-order, just like
TCP reorder or IP reassembly, it ca
At 9:49 AM -0500 4/9/12, wrote:
>At 4:50 PM + 4/6/12, Xiangyang zhang wrote:
Stephen,
You understand this method very well. The disadvantage is the possible
severity of out of order delivery. Even with single SA, it can also
cause the out of order problem. As for re-order, just like T
At 10:11 PM + 4/9/12, Xiangyang zhang wrote:
Steve
Even though TCP or IP does not envision it, the ordered processing
is very common now. In an intermediary node, IP reassembly and TCP
reorder must be done some time. In flow-based technology (for
example, stateful firewall), without IP
I provided a number of comments in response to the -00 version back in
April.
According to the diff tool in data tacker, the -01 version is identical,
except that the author list and dates have changed.
So it's not clear that comments really are "appreciated.";-)
Steve
___
Dan,
My recollection is that the agreement at the SECDIR meeting was that a
waring of the form "not for use with IKEv1" was part pf the deal. I
still believe this is a very questionable way to accommodate the IEEE's
unwillingness to maintain their own registry, and their slow doc rev
cycle ti
On 1/4/13 3:23 PM, Andrey Jivsov wrote:
...
Point compression is more beneficial for storage security for reasons
of performance and storage efficiency. For storage efficiency side:
when there are multiple recipients per message, each associated with
one ECDH-related field, it's possible for
Folks,
I think my initial concern has been misunderstood, or maybe I
misunderstood the
purported benefits of the proposed mechanism.
When I asked about compatibility with existing S/MIME specs, I was not
referring to
details of how the EC public key is represented in a cert, per se.
Andrey
Sheila,
I did a quick check of 4301, and it uses the term "confidentiality"
consistently when referring to the service, and uses "encryption" to
refer to the mechanism. They are not used interchangeably.
The same seems to apply to use of terminology re data origin
authentication, integrity, et
Sheila,
I understood your point. I objected to your statement that other IPsec
RFC were
sloppy in the use of security service/mechanism terminology.
Steve
Steve,
Perhaps I wasn't clear in the main thrust of my message. I'm not quibbling
about terminology; I'm concerned that the I-D is lack
Mike,
A couple of your comments caught my attention, as an author of 4301, 02,
and 03. I admit to not having read the DMVPN proposal, so my comments
are based only on your message, which argues why DMVPN is the preferred
solution.
IPsec encryption layer. In this layer ISAKMP/IKEv2/IPsec is th
Mike,
Thanks for the responses to my comments, including ones from yesterday's
meeting.
Steve,
Sorry, I wasn't clear on our use of IPsec. We definitely use both the
authentication and encryption capabilities of IPsec. We do the
following when bringing up a new tunnel.
1. Trigger ISAKMP/IKE
Manish,
Hi Stephen,
Thanks for your inputs vis-a-vis 4301/2/3. I concur that IPSec is
not just about encryption but don't quite buy into what somebody
spelled out during the meeting as 'IPSec is an access control
mechanism that also provides other security services'; IMO, strict
access con
Manish,
Steve,
To answer your question, the SPD entries are not already there, they
are created as the result of a message exchange between the two
spokes; it's the spokes that choose the policy, not the hub. If the
SPDs were already there, every IPSec node in the network would need to
know
Manish,
Steve,
NHRP is used to resolve the remote peer which serves/owns the address
we're interested in. The information in this resolution culminates in
the creation of SPD.
So the NHRP interaction creates a new SPD entry as a side effect? This
entry is
more specific re selector values (for
Fred,
Thanks for the detailed answers to all of my questions.
I look forward to seeing the description of how DMVPN relates to the
processing model defined in RFC 4301 (Figures 1, 2, and 3).
Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf
updated versions of RFC 4301, 4302, and 4303 have been posted:
Title : IP Authentication Header (AH)
Author(s) : S. Kent
Filename : draft-kent-ipsecme-ah-rfc4302bis
Pages : 35
Date : Nov. 19, 2013
This docum
/19/2013 11:06 PM, Stephen Kent wrote:
updated versions of RFC 4301, 4302, and 4303 have been posted:
Thank you Steve for working on these drafts. These drafts are targeted
at republication as Internet Standards. As promised in Vancouver, I
would like to open the question of whether we should be
For progress to Internet Standard, we need to verify the status of
implementations
relative to the RFCs. Rather than Going through an exhaustive list of
MUST and
SHOULD compliance, let's start with a simpler list, suggested by Sean.
I request that each implementer complete the following form:
Same drill for 4303:
*The following questions document whether the syntax and semantics of the
protocol were implemented:
- Which of the following ESP packet formats does your implementation support:
- separate encryption and integrity algorithms:
- combined mode algorithms:
- W
Responses to the 4301 and 4303 questions should be posted to the list.
Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Yaron pointed out that the reference to RFC 6401 was in error. The relevant
RFC is 6040 (Tunneling of Explicit Congestion Notification).
Sorry 'bout that,
Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Saurabh,
Hi,
We'd prefer
dmvpn(http://tools.ietf.org/html/draft-detienne-dmvpn-00) to become
the wg document.
The main reason for our recommendation are:
- It is what customers are asking for.
This statement may represent a lot of skew if the sample set if Cisco
customers who are told th
Paul,
On Feb 25, 2014, at 8:48 PM, Yaron Sheffer
wrote:
Hi, this is to start a 2-week working group last call on the revised
Algorithm Implementation Requirements
document, ending March 11. The draft is at:
http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We
should have last c
Paul,
On Wed, 26 Feb 2014, Valery Smyslov wrote:
It is for systems that don't implement AH. We should probably say
this explicitly in section 3.
I don't think it is limited for those systems only.
You may implement AH, but yon cannot use it
everywhere, as it is not compatible with NATs.
And E
Paul
On Mar 8, 2014, at 8:08 AM, Black, David wrote:
The next draft changes AES-128-CBC to AES-CBC, and says:
In the following sections, all AES modes are for 128-bit AES. 192-bit AES
MAY be supported for those modes, but the requirements here are for 128-bit
AES.
What about 256-bit AES keys
Paul,
...
It's good to remember the reason that 256-bits keys for AES were specified,
i.e., as a hedge against someone building a quantum computer. So, unless the
data being encrypted is expected to have a lifetime far enough into the future
as to merit protection against that concern, the extra
Daniel,
I read the very brief IV-generation I-D and I didn't see an explanation
of how
to perform IV "compression." As someone else already noted on the list,
an IV
is carried with each packet to enable decryption of packets that may
arrive out
of order. Thus it's not enough to have each peer
Daniel,
Thanks for the explanation.
...
The draft does not specify how matching between IV_i and packet i is
performed.
- 1) you may use the SN as the packet counter. Of course it is
easier if the SN increments for each packet. However SN are not part
of the IV generation.
which SN? the o
Ashok,
Hi All,
As per my understanding, the anti-replay feature in IPsec helps to
save CPU cycles
in the IPsec gateway (or host) by discarding the replayed packets so
that costly
operation like MAC calculation and decryption can be avoided for such
packets.
Is my understanding right?
only p
Yaron,
I re-read the new draft and I must say it is much clearer than the
previous version. Still, a few comments:
*
* We are still using IP addresses to identify peers: "if an IKE peer
receives... from an IP address that matches a configured
connection". I think an IKE peer that
Paul,
Other authentication methods defined for IKE perform authentication, so
there was
no need to express anything special in the SPD or PAD. NULL is obviously
very
different.
The text you cited from 4727, with the edit you proposed would be a big
improvement.
Steve
_
As the primary author of 4301, and the creator of the PAD, I believe
this work
does update that section of 4301. I agree with Kathleen that this doc
needs to
say precisely what parts of 4301 are being updated, perhaps using a
before/after
approach.
Steve
On Apr 1, 2015, at 6:57 PM, Kathleen
Yoav,
Hi,
There is two questions I would like guidance from the group about.
First is the nonce/IV question: In the current draft, there is a
64-bit IV with guidance not to repeat them (so use a counter or LFSR).
The function itself accepts a 96-bit input nonce, so the nonce is
constructed
Yoav,
I think it’s risky to base decisions on our attempts to divine future NIST
decisions, but I agree that out best option now is to leave the 64-bit IV (or
nonce) explicit for now and perhaps later add an IKE extension that allows you
to “compress” the IV as long as it’s equal to the pack
Yoav,
Is this code available anywhere? If not, it makes it hard to reproduce
their results.
There is a paper on the code design, and I anticipate the code will
become available,
as the work was sponsored by NIST.
It’s too bad they don’t submit this to bench.cr.yp.to so we could have
an apples
Paul,
It's been over 8 years since this RFC was published, and I have not
looked at it since then. My recollection is that we wrote 5114 because
an IPsec developer approached me and said that he wanted to support
these groups in a product. He said that he wanted test vectors for the
groups,
Pasi,
I agree with your observations/concerns. Any host/SG to which one is
redirected needs to be subject to the same controls as an initial SA
target. I see this as a PAD (and SPD) issue. I would suggest that
maybe the only safe approach is to reevaluate the redirected target
against the P
At 4:27 PM +0530 3/25/09, Prabhat Hegde wrote:
Hi,
In case we do QOS re-ordering (caused due to shaping &
queueing) for traffic classes after encryption, the encrypted pkts
get re-ordered thus changing the order of sequence numbers. At the
receiving end, such out-of-order pkts are droped
Prabhat,
With regard to your first observation, I'll note that your argument
appears to be based on particular implementation choices. We don't
generally consider changes to standards based on such choices, unless
a lot of vendors indicate that there are no viable implementation
options consi
At 2:18 PM +0300 4/29/09, Tero Kivinen wrote:
...
In most case I would not expect Bob to create the old SA that way at
all, as it would require it to combine two SPD rules together when
accepting such entry. As the SPD entries are ordered list that would
mean it was combining two entries which h
Pasi,
It is true that 4301 does not require that the SPD be implemented as
an order list of entries. In fact, 4301 specifically adopts a
de-correlated SPD model to explain the details of processing.
Steve
___
IPsec mailing list
IPsec@ietf.org
https:
At 7:40 PM +0530 5/11/09, ss murthy nittala wrote:
Hi,
Is it required for IV to be randomly generated for each ESP packet
in case of AES-CTR and AES-CBC methods?
AES-CTR:My understanding is that IV is to be generated randomly for
the first packet.For each new outgoing packet increment IV and
2405 is out of date. Its recommendation re using the last 8 octets of
ciphertext from the previous packet has been replaced with one of
using a randomly-generated IV for each packet.
Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mai
If we elect to keep the next header field, to help middle boxes
quickly locate header fields of interest to them, then we MUST
require the recipient of each message to do a (well-defined)
consistency check on the packet, for the reasons I cited in SF.
Steve
___
At 9:34 PM +0530 5/12/09, Murthy N Srinivas-B22237 wrote:
Is there a new draft/rfc posted with the change incorporated?
-ns murthy
DES is deprecated, so I would not expect a revised RFC on that. AES
is strongly preferred over 3DES, so there is little incentive to rev
that doc, although it m
At 10:11 AM -0400 5/22/09, Gunduzhan, Emre wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D203aplesstripedo_"
Greetings,
I am new to this group, so I hope I am not raising an issue which
was addressed earlier. I
At 9:08 AM -0400 5/26/09, Gunduzhan, Emre wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_068F06DC4D106941B297C0C5F9F446EA3CB241D43Faplesstripedo_"
Steve,
Thanks for the clarification. So, at the end of the initial IKE_AUTH
exchange, there will (typi
Yaron,
Add me to the list of folks who does not understand how a locally
meaningful name works. I'd like to see a more thorough discussion of
this notion before we proceed.
Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/li
At 2:57 PM +1000 7/27/09, Greg Daley wrote:
...
Your reference to 4301 regarding the use of multiple parallel SAs solving
the example is helpful. I will remove the example for clarity.
As Tero noted, RFC 4301 provides a discussion of how an
implementation can, on a local basis, deal with map
At 12:52 PM +0300 8/15/09, Yaron Sheffer wrote:
C
This document does not specify a mandatory-to-implement or a
mandatory-to-use ticket format. The formats described in the following
sub-sections are provided as useful examples, and implementers are free to
adopt them as-is on change them in any w
At 11:46 AM -0400 9/11/09, Marcus Wong wrote:
Hi Everyone,
I'm new to the working group. I've uploaded a draft on the use of notify
payload for integrity data exchanges in IKEv2 for your comments and review.
All comments are highly appreciated. Thanks everyone.
A new version of I-D, draft-wo
At 4:06 PM -0400 9/11/09, Marcus Wong wrote:
Steve, you are mostly right, but this I-D only deals with the integrity data
exchange using the notify payload. Thanks.
Marcus
Thanks for the clarification. That still raises the question of why
we ought to duplicate this NEA functionality in IKE
Marcus,
Thanks for the additional background. I am not an expert on 3GPP. Do
you know if there an IETF liaison to the 3GPP? If so, the right
approach is to have that individual coordinate an action like this
between the SDOs, i.e., when SDO-A wants SDO-B to modify/extend a
protocol to accommo
At 11:29 PM +0800 10/14/09, Zhen Cao wrote:
O...
> IPv6 hosts, like IPv4 hosts, run Linux, BSD, Windows or some other OS. With
> most of them, the latest versions support IPv6 for IKE and IPsec.
I guess we do not need tunnel model for IPv6 ipsec?
what makes you say that? unnelT mode is still
Jack,
I would have no problem deprecating AH in the context of the IPsec
architecture document, if others agree. It is less efficient than
ESP-NULL. However, other WGs have cited AH as the IPsec protocol of
choice for integrity/authentication in their environments, so there
will be a need to
At 7:44 AM +0530 11/12/09, Bhatia, Manav (Manav) wrote:
Steve,
I would have no problem deprecating AH in the context of the IPsec
architecture document, if others agree. It is less efficient than
ESP-NULL. However, other WGs have cited AH as the IPsec protocol of
choice for integrity/authe
At 7:49 PM -0800 11/11/09, Merike Kaeo wrote:
All of the standards I've seen that explicitly define how IPsec is
to be used for authentication (including RFC 4552 -
Authentication/Confidentiality for OSPFv3) say that for
authentication ESP-Null MUST be used and AH MAY.
Which RFCs specify AH s
At 6:48 AM +0530 11/13/09, Bhatia, Manav (Manav) wrote:
Daniel,
AH is a security feature we need to keep for header authentication
Am really not sure about the value that AH adds even in case of
header authentication.
So what fields does AH protect:
Version, Payload length, Next Header,
I agree with all of Paul's observations. The scope of this profile is
entirely appropriate.
Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
My message pointed out that there was no mention of options, Your
reply picked a couple of option examples and argued that they were
either not used or did not pose a security problem.
The right way to generate a god answer is to construct a table of all
the options, and provide a rationale f
At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote:
This is an implementation specific optimization that has already
been solved in multiple implementations.
Cheers, Manav
Is the phrase "implementation specific" a euphemism for non-standard?
Steve
...
Divine guidance is, I suppose, one way to do protocol design, but it
could lead to *real* religious wars
an appropriate caution given my typo :-).
>
Also, note that IPSO and CIPSO are examples of options that were
discussed at the IPSECME meeting this week, where there is a need
At 11:03 AM -0800 11/17/09, Gregory Lebovitz wrote:
inline...
On Mon, Nov 16, 2009 at 8:18 AM, Stephen Kent
<<mailto:k...@bbn.com>k...@bbn.com> wrote:
At 7:50 PM +0530 11/16/09, Bhatia, Manav (Manav) wrote:
This is an implementation specific optimization that has already
be
At 11:09 PM +0530 11/21/09, Jack Kohn wrote:
Steve,
4301 contains We have explicit directions on how to use multiple SAs when
the peers know that they want to send traffic with different QoS parameters.
This appears to be an instance where the middle boxes are to examining
traffic, and put
...
>- it fails to characterize the range of protocols for which you
believe this argument applies,
http://www.ietf.org/mail-archive/web/ipsec/current/msg05070.html
This is one example, we could think of some more.
This is only one example, and I think it is not "mainstream", so mo
At 9:05 AM +0530 11/25/09, Jack Kohn wrote:
>
>...
Assume we dont have WESP.
The end router having scores of OSPF adjacencies will have following
rules in its database for *each* adjacency:
Incoming Pkt carries SPI X, then look at the nth bit and if its a OSPF
HELLO, put it in Ospfv3HighPrio
At 12:11 PM +0100 11/25/09, Daniel Migault wrote:
Hi Manav,
I agree that for an already negotiated SA, the SPD lookup detects IP
source address spoofing. So in that case ESP detects the address
spoofing during the SPD check whereas AH would detect it while
checking the signature check.
Howe
Jack,
Thanks for describing the additional selection criteria that must be
employed to avoid the problem I cited.
Given this more complete description of the selection criteria, I am
not convinced that that is a significant benefit for using WESP in
this context.
- Whether using WESP or j
I think that there has been insufficient discussion of whether those
who wish to make use of IPsec to enforce mandatory access controls
require the facilities described by the folks who have proposed this.
At the WG meeting 2 weeks ago I made two observations:
- possible use of CIPSO for c
I am opposed to pursing this work at this time. The ongoing
discussion on the list suggests that the arguments put forth for WESP
use in the OSPFv3 context, the first concrete proposal outside of the
middlebox inspection context that motivated WESP, have not been
validated. The presentation
Folks,
I think there is merit to pursing both the EAP-based and the
SPSK-based password authentication proposals as WG items. My
rationale is:
- EAP-based methods are well-suited to client-server
interactions and to enterprise environments that already use
RADIUS/DIAMATER. Unfortunately,
Brian,
I wasn't sure, form your brief description, whether you envisioned
any crypto protection for this version of WESP. If not, then this
added info is not protected and might be modified en route. This
seems like a possibly dangerous feature, as it says that we are
causing an intermediate
At 6:24 PM + 12/7/09, Brian Swander wrote:
0 - option data does not change en-route. This option is
included in the WESP ICV computation.
We'll be using this flag, so this option will always be integrity protected.
integrity protected for checking by the end system, but not
verifiable
At 7:50 PM + 12/7/09, Brian Swander wrote:
In case it wasn't clear for the earlier WESP discussions, we need
this to also work with simple transport mode: i.e. not just
transport mode inside tunnels terminating at various infrastructure,
and not just in tunnel mode.
The transport nesting
Paul,
From your comments it seems as though an IP option would be
preferable, as it is not IP-sec-specific, and it an be protected if
needed, in the IPSec context, e.g., via tunneling.
Steve
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org
At 5:20 PM + 12/9/09, Brian Swander wrote:
AH alone isn't good enough. We need solutions that also work with
end-to-end encryption.
bs
I think you are saying that it is a goal of those who are proposing
the WESP extension work item to move beyond the original, stated
goals of WESP, and
At 8:20 AM +0530 12/18/09, Raj Singh wrote:
...
IKE is Internet Key Exchange protocol NOT IPsec Key Exchange protocol.
IKEv2 is not just a mean of exchanging keys but its a full package.
This package provides mutual authentication, keys and readiness to
secure data as needed.
The main motivati
Yaron,
I hate to admit it, but I lost track of the details of WESP as it
progressed through WG discussions and briefings at IETF meetings.
When I read the I-D in detail, I was very surprised to see that it
was no longer a neatly-layered wrapper, as originally proposed. The
fact that it now c
At 6:17 AM +0530 12/29/09, Jack Kohn wrote:
Are you suggesting that ESP ICV should not cover the WESP fields?
I think, and my memory could be failing me, that this was discussed in
the WG before this got added to the draft.
Jack
I am suggesting that WESP should be cleanly layered, in one of t
At 12:27 AM +0200 1/5/10, Yaron Sheffer wrote:
Hi,
We have had a few "discusses" during the IESG review of the WESP
draft. To help resolve them, we would like to reopen the following
two questions to WG discussion. Well reasoned answers are certainly
appreciated. But plain "yes" or "no" would
At 11:14 AM -0700 1/5/10, Grewal, Ken wrote:
Yes to both, based on arguments already discussed numerous times in
the WG via presentations, 12 iterations of the draft and multiple WG
last calls + AD reviews!
The main motivation for extending the ICV was to counter some of the
issues originally
Gabriel,
...
One may argue whether that consistency check is best served by
extending the ICV to include the
WESP header fields (per the current WG consensus as expressed in the
existing draft), or whether
that is best done by the end nodes checking the fields explicitly.
My reply to Ken a
At 10:10 PM + 1/5/10, Brian Swander wrote:
I'll resend my message from earlier today that gives a concrete
scenario for why the WESP encryption bit is in charter.
To satisfy the existing charter item, we need a deployable solution,
which entails working with legacy systems that don't supp
At 9:45 AM +0530 1/6/10, Venkatesh Sriram wrote:
> Would it help if WESP is renamed to something else? Since we're
discussing the fundamental principles of the protocol, i see no reason
why we cant change the name, if that helps. I think its the "Wrapped"
in the WESP thats causing most heart
At 5:19 PM +0200 1/6/10, Yaron Sheffer wrote:
I would like to reframe the migration discussion. Manav, Scott and
everyone else, please correct me if I got it wrong.
Suppose we have a middlebox that can do useful things if it knows
that the flow is unencrypted, and only basic things if it is
e
At 5:42 PM + 1/6/10, Brian Swander wrote:
The uplevel machines can't use ESP to send the encrypted traffic in
this scenario. Remember, that we need to look at the holistic
scenario of how to deploy this in an environment where we have
legacy machines that don't do WESP. And we need to sat
At 8:56 PM +0200 1/6/10, Yaron Sheffer wrote:
Hi Steve,
Please reread my text. I was (in that paragraph) taking Manav's
side, i.e. assuming there's value in deterministic distinction
between encrypted and unencrypted ESP, and hence, gradually moving
the endpoints to WESP so that middleboxes h
1 - 100 of 117 matches
Mail list logo
