ed this is safe, but I'm thinking about
it.
Thank you for the document.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
IPsec mailin
/ipsec/9_hkyF3P7Nq5oEOPc73v6i2gdLU/
2 emails.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
IPsec mailing list -- ipsec@ietf.org
To unsubscrib
irdly let one traceroute in the reverse direction too, only
the ICMPs would go to the receiving host, which is not the host doing the
traceeroute, so not very useful actually.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
s
Panwei (William) wrote:
> If you want to do the traceroute to determine how far ESP actually
> gets, you need to make sure every node supports the ESPping.
No, only the final machine.
Others would respond with ICMP unreachable when TTL=0
--
Michael Richardson , Sandelman Software
cket. The machines in the middle do not need any
> special support because any packet that hits TTL=0 should solicite
> an ICMP response.
That's right, and we yeah, we can do that immediately.
Perhaps obviously: The responding server needs to implement this protocol in
order to get a reply though
irewalls until they understand that UDP!=ESP.
> When you find out that the IKEv2 negotiation succeeds but ESP traffic
> can't get through, what more information will you get from sending the
> ESPping and not receiving a response?
That there is a problem with proto=50... So:
sytem into a previously working site-to-site VPN and suddenly things
stop working, or get poor performance.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
__
hink that this traffic is control plane traffic that allows for the
mobility of the devices attached to these base stations. I don't know the
3GPP protocol names for that.
But, does it also include encapsulated end-customer traffic?
I would assume that each base station has an SA to connect it to
at you need.
For instance, do you have issues of traffic accounting between the RANs that
occurs on the outside (ESP) packets.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
Jen Linkova wrote:
> On Wed, Feb 28, 2024 at 7:12 AM Michael Richardson
> wrote:
>> In github issue: https://github.com/furry13/ipsecme-esp-ping/pull/6
>>
>> I said: >I am not in favour of any link to IKE.
>>
>> I d
the way.
In the process, they discover some IPv6 firewall which thinks only TCP and
UDP exist, and it gets fixed.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Des
ESP can be turned into an ESPinUDP
without affecting the crypto. Why would the network or attacker want to do
that? I dunno.)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Descript
Jen Linkova wrote:
> On Tue, Jan 23, 2024 at 10:10 PM Michael Richardson
> wrote:
>> While the whole point of the SPI7/8 mechanism is that it can be operated
>> completely without IKEv2 involved at all.
> So I was working on the text which focuses on S
s that it can be operated
completely without IKEv2 involved at all.
I would prefer to adopt this document to solve the primitive diagnostic
problem. There are a number of problems/challenges in the currenct solution
which I think that the WG can address, once we agree on the problem we are
t
t the reserved SPI concept is worth standardizing,
because sometimes it's just really basic debugging one needs.
Being able to puzzle through a series of nodes where one is screwing with
ESP, and being able to "up-arrow-return" to try again is a good feature.
--
Michael Richardson , Sand
mechanism. That we should
simply have the kernel report receipt of PING/discard packets (on SA #1234)
to the IKE daemon, and let it do the correlation.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signatu
isn't really the goal.
The goal is more: Is there something in the network that prevents us from
speaking IPsec to x.x.x.x?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Desc
know that they are related, but in general 4301 says that kind
of thing belongs up in the key manager.
My opinion (also as a new co-author) is that we should not attempt to support
echo request/reply for existing SAs.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
these TS can be created
> until the peer again blocks you with a TS_MAX_QUEUE.
Do you think it be better for each end to announce a maximum ahead of time?
(At negotiation of the first child SA)
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
An attacker that can see into your IKEv2 packets, can also do many other
things. They are a peer. I think this is poor advice.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
]
tunnel).
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
receive same processing in the internet.
Are the two ends/sites in the same administrative domain?
> I think the easiest way of doing that is to add DSCP Status Notify and
> use it like this:
I agree.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software
ation
> would be pretty bad.
yeah, I don't know exactly how to do the userland communication.
How specific does it need to be is my question? How express that.
Looking at mtu-dect, I'm unclear how the LMAP and and PTB describe the flow
which has the MTU concern. It's mostly clear when i
because cisco pix default configuration of 20
years ago) is because IPv4 home routers fix the MSS.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
ct to the work getting standardized.
In particular, for networks where there are MTU constraints on the far side
of the far gateway, telling the sending gateway about the MTU has a far higher
chance of working than anything else. The sending gateway probably can send
PTB ICMPs with better results.
--
M
kets and then fragment them, even with IPv6.
DF=0 for IPv4 on ESP packets is good, until there is a firewall that cant
cope with fragments.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signatu
adding or not, so we can
really just do whatever.
I suppose it would be good to have a value at the beginning of the packet
(closer to what an ICMP PTB might successfully return upon failure) to say
how big the packet was.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sand
an ESP SA and try to go into an ESP-in-UDP SA, and it might
not fit.
Many people would like to use 9000 byte ethernet across VPN links.
Such as the physical people.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
sign
east
1280, ideally 2048 bytes in size.
that would let us diagnose MTU issues better.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
nd it ALSO makes
no sense to negotiate DSCP as a traffic selector.
I see Joel Halpern as a co-author.
Perhaps Joel can better articulate what real world problem this is really
trying to solve.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and
l against the IKE
socket that would turn on ESP Echo Request processing.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
ross all the ASBRs, using a distributed database.
I agree.
There will communities that will want to implement a standard so that they
can buy commodity silicon for the ASBRs, but they don't need IETF.
If they do want something, there is FORCES: (RFC3746 and friends).
--
Michael Richardson.
the packet isn't for the ASBR, and won't get processed by
it.
So, either your transport mode has to change the destination address on the
packet, and recover/store the real one somewhere (much like SR6 does), or,
it's really some kind of L2 function going on here, and not really IPsec at
> (esp. [1][2]) should be in the same WG as RISAV, as it depends heavily
> on that capability.
We have to get simultaneous IPsec, 6man and BGP review.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
WG in the routing area with a SecAD
owning it.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.
Tero Kivinen wrote:
> I mean what should other end do if the other end says he will not
> do anti-replay checks?
Not send unique relay values in the ESP.
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
fication in case no IKE SA exists).
>>
>> Fair enough, but those are inside the IKEv2 PARENT_SA, while GSA_REKEY
>> is not.
> GSA_REKEY is "inside" a multicast rekey SA (which is different from
> initial GM<->GCKS IKE SA).
I think that this new SA needs
d 802.15.9 standard
> (March 2021) specifies that G-IKEv2 is used for group key distribution
> (but I'm not involved in this work).
Almost nobody other that Tero has implemented 802.15.9/IKEv2.
(That's a shame, and I wish it weren't so, but sometimes you have to respect
the mark
g PPK (defined in drft-smyslov-ipsecme-ikev2-qr-alt).
It seems like it belongs in smyslov-ipsecme-ikev2-qr-alt.
I don't feel strongly.
>> Who has implemented?
> As far as I know early versions of the draft (incompatible with the
> current one) were implemented by Cisco and by Tobia
IKEv2, rather than a new
protocol. I think that IKEv1 was lacking enough orthogonality for that to
have been practical before.
I'm not sure if section 6.1 belongs here.
Who has implemented?
Or maybe I should instead ask: who cares?
--
Michael Richardson. o O ( IPv6 IøT consulting )
t; referenced, or if not, it might be helpful to:
> - in Section 5, unambiguously specify what is meant by deprecated.
> - in Section 7, bind the definition of the Status column back to Section
5.
I'm not sure that a more precise definition will really help.
Section 3 is also p
eep the draft alive, and
when (if?) draft-guthrie-ipsecme-ikev2-hybrid-auth finds some implementation,
that it will all be ready.
(by which point, many peple will have read auth-announce will many users)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works
enough.
(i.e. allocate it a Notify value, and just let it wait for some more people
to implement it.)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
initiator and responder.
It seems that if one wants a particular safety against a Grover universe,
that we should update RFC8247, or create a companion document.
I don't think that we should embed everything in this document.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sand
that we have goals which are really two goals.
{I think we are in complete agreement about how such a virtual interim should
go}
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
De
I don't think that the constrained problems are really a good mix at all into
a higher-performance ESP. We are talking about 10 to 12 orders of magnitude
difference in network performance.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa
e
might agree are out-of-scope, or are really implementation specific issues.
That might mean a document be written, and the WG do a consensus call.
> - How should the problems be solved?
> Please let me know if there is interest,
Thank you for bringing this up.
--
Michael Richa
I have read draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt in it's various
forms over the years, and again just now.
I support adoption of the document and rapid publication.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
e) solutions might involve
having actual hardware, so it may not as trivial as just changing a few lines
of code.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing l
002 "dooku--ipv6" #14: Bid-down to IKEv1 attack detected, attempting to rekey
connection with IKEv2
I've NEVER seen a real one of these in the field. I'm on a Eurostar train's
wifi.
Could it be some helpful NAT44?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT
Ben Schwartz wrote:
> On Mon, Oct 31, 2022 at 2:52 PM Michael Richardson
> wrote:
>>
>> {some of my emails have written "ABSR" rather than "ASBR". Oops}
>>
>> Ben Schwartz wrote:
>> > On Mon,
{some of my emails have written "ABSR" rather than "ASBR". Oops}
Ben Schwartz wrote:
> On Mon, Oct 31, 2022 at 11:46 AM Michael Richardson
> wrote:
>>
>> Michael Richardson wrote:
>> > Based upon conversations on the lis
Michael Richardson wrote:
> Based upon conversations on the list, this proposal might not even be
IPsec.
> At least, it's not proto=50(ESP)/51(AH), as they are asking for a new
> extension header type.
> The proposal would require allocation of a SPI for a destina
k
that what they have created is a protocol for dealing with fragmentation
beyond the far gateway.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
The other question is whether or not we can just leverage RFC9268 to do this.
This is a recent 6man innovation.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing
d idea to do SOMETHING.
I think that it's very SR6-ish, and since it is cross-AS, I can't see how
6man will approve.
It might be appropriate to at least ask SECDISPATCH.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP sig
HKDF(IKEv2 DH key, source IP)", and then ESP
mode
> would run pretty much as usual. My main question was how to negotiate
this
> in the IKEv2 handshake.
You would be negotiating something new that's not ESP or AH.
> In terms of performance, my bigger concern is that
nsions"
> mentioned in Section 5.2 and Section 5.3 of RISAV, so it's definitely
> relevant. Too bad it doesn't exist...
I think that SKIP is probably the best direction to think about.
Some ex-SUN people will buy you drinks until you die if you go that way.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
mode IPsec encapsulation.
> If it’s such a trusted one hop, why do you need IPsec to signal a traffic
label?
It's not one hop. It could transit multipls ASs.
That's why they are so concerned about MTU, and why IPTFS might help make
this deployable.
--
Michael Richardson , Sandelman
ISPs since them have rejected any forwarding engine that can not
produce the same kind of statistics. They really want to know how much
traffic is port-80 vs port-25... Of course QUIC screws that all up.
Many routing fabrics have internal mirror "ports" that actually do the 5-tuple
accountin
I haven't found in the draft an explanation of where the original source and
destination address would go. IPsec SPI are seat specific, the ABSR can't just
eat AH headers from packets that were not addressed to it.
--
Sent from my Android device with K-9 Mail. Please excuse my
s well do this.
}7.3. MTU
}
} TODO: Figure out what to say about MTU, PMTUD, etc. Perhaps an
} MTU probe is required after setup? Or on an ongoing basis?
The answer is probably to do IPTFS, but that is in conflict with using AH.
--
Michael Richardson , Sandelman Software Wo
I think that the point is that even if there are n CPUs, that a sensibly
designed system might well have n+1 SAs active.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
e re-keyed or even deleted if they are idle
> for a long time.
If there are SAs which are being used more than others, than there is
something wrong.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc,
Pv6,
then that might be a win-win.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
me way this could be useful for SAV?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
community to improve and clarify these tech drafts.
They aren't not yet mirrored to my laptop, but I'll read them as soon as I
have Internet again.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
__
Yes... if there is any doubt, the expert can come to the list with questions.
I've seen other experts do this regularly.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_
ber of different ways to be sure.
We decided not to go that way because we felt that it was a waste of a very
scarce resource.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signat
ve all mention of PMTUD.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Robert Moskowitz wrote:
> Here is the latest revision.
> Should this draft be adopted by the workgroup for 'proper' document
> advancing?
adopt it, and WGLC it.
It's done.
signature.asc
Description: PGP signature
___
IPsec mailing list
them ? Maybe the chairs or AD could give
>> guidance here
> I think I could have the IANA Considerations have a fix for 1 - 3 as
> well as add 4.
> I will work something up and share it here..
Couldn't the IESG just provide IANA some clarifying guidance her
d public could be added all over the Registry.
I think that RFC4025 has the word in enough places that it should be obvious
that a private key does not go there.
So this seems like printing "This bag is not a toy" on stuff, but I don't
object to this.
, it ends up in the DNS HIP
> RR. We don't want the initiated to think this is a place for private
> keys...
I have read it and it looks good.
I would ask that there be an example of a public key in an appendix, and that
private key be included.
Shouldn't you cite RFC4025 somewhere?
--
Robert Moskowitz wrote:
> This is an item that goes back to the beginning of ESP work:
> Minimally, how does the higher level 'learn' that it is secure:
Are you asking how *TCP* learns of this, or how an application with an open
socket(2) learns of this?
>
your list, and I agree with them all.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Thank you for the summaries.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org
w/3DES+MD5?
Having said this, I do not object to the WG doing this work, but I won't be
taking time to review it.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing
ginal rfc, but I think that it's a good
> idea to add them to acknowledgement section anyway. Will do this.
Glad to hear you had that discussion. My issue is closed :-)
Please consider using the xml-v3 contributor mechanism.
If you are using Kramdown, then it's just like the author: secti
ts they are used very intensively.
>> But I don't have any real life stats for them.
>>
>> Regards,
>> Valery.
> I also implemented puzzles. So that makes two of us.
Did you ever interop?
What is your criteria for enabling them? Do you do this aut
their
contribution was to the original document, nor do I know if they were asked.
If the design team has gone through this consideration, then that's enough
for me.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
I've read the diff, and it looks good to me.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
Tero Kivinen wrote:
> Christian Hopps writes:
>> Will you be able to provide the text changes that would cover the
>> issue you have? Would really like to get this submitted to IESG
>> before another IETF cycle completes.
> How about following:
works for me.
the IKEv2 is at all
> modified with addition to the multiple ke, or beyond 64k limit drafts.
I agree.
IKEv2 is not SSLv3.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
> list to make it more informal and not look like it is claiming a
> complete list of items.
Great.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
document submitted to the IESG.
(And the IESG has become even more active, so it could still take many
revisions to get to publication)
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP
is not our area of
>> expertise, and we have already received approval from the experts for
>> the text that we have. Let’s stick with the approved text and make
>> clarifying modifications only.
I understand and agree.
Maybe clearly pointing at what text is involved w
I think you'll all be happier with a virtual interim meeting with no conflicts.
We can now use meetecho even.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
the list. Since this is rather new, short messages in the vein of
> “Yeah, this is good. Ship it”, but substantive comments are, of course,
> even more welcome.
Re-read to be sure.
Ship it.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc,
Paul Wouters wrote:
> On Sat, 13 Mar 2021, Michael Richardson wrote:
>> I'd *like* section 3 to enumerate the claims clearer (Maybe just new
>> paragraphs).
> You mean a textual change? like split out more, or bullet points?
Yes. I am imagine a
the byte counters.
The use of the word "octets" is traditional in MIB documents, going back to
the 1980s, when ASN.1 originated.
Some machines had 9-bit bytes and 36-bit words :-)
I also support adoption.
--
Michael Richardson , Sandelman Softwa
im, and I think that they
should point to references. That will make it much more impactful a
document in my opinion.
But, I'd rather publish it if adding such references is hard.
I think that the third paragraph (labelled IPsec) should be a new section
3.1.
--
Michael Richardson , Sandelman Softw
that it failed if I get a sender timestamp X (getting X+1),
that the oversize packet was lost.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_
ut traffic that was dropped?
I'm on about this, because I think that PMTU issues are among the biggest
problem for IPsec.
If we can auto-tune the tunnel size, that's really a killer use.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and W
is really worth supporting?
> It doesn't take much to continue to allow for unidirectional use at the
> lowest layer (ESP/SA). It isn't relevant once you get to IKE where
> bidirectionality is required.
I think that maybe this is in the MAY.
It's isn't clear to me if I need to support that or not.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
FS) and it's utility beyond
> that application is certainly a bonus -- the very recent name changes
I agree.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description
breakers to us
non-transport-types.
> If the SA back to the sender is a non-
>AGGFRAG_PAYLOAD enabled SA then an AGGFRAG_PAYLOAD empty payload
>(i.e., header only) is used to convey the information.
is this really worth supporting?
Please break up third paragraph.
=
--
Michael Richa
the payload type some other way *has* to be
> seen as a hack. Why do we need a hack?
I don't understand either.
Can we just let these guys get on with their work?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
Hardware is not going to have more than two ciphers.
If as many as two.
Again, I suggest you write an Informational document, as for a code point,
and submit through ISE.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman So
Michael Richardson wrote:
> Hi, I finally got to watching your presentation on the IETF youtube
channel.
> the illustration at https://youtu.be/IrNsFAPhx-Q?t=3410, which I guess is
> also at:
>
https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-
1 - 100 of 347 matches
Mail list logo