nce TLS is involved, things become different, unless you want to build
> a TLS stack into the kernel :P
There are a multitude of TLS accelerators that live "below" the kernel.
--
Michael Richardson , Sandelman Software Works
-= IPv
eal IKE packets,
and send it to an existing daemon.
--
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
want it?"
"Before IPv10 is deployed!"
--
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
sec
> tunnels, one for each host.
Good point, but that's not, I think, what she was asking for.
Perhaps Linda can clarify her question.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_
nda> the other end)?
A single IPsec (4301) tunnel can service traffic between two subnets.
In IKEv2, we use negotiate ranges (which is a super concept) rather than
subnets.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signat
led PPK. If the authentication (and
> Diffie-Hellman) cannot be broken in real time then authentiation will
> prevent attacker disabling PPK.
Agreed, but I don't think this mandates that one load all the PPKs at the
same time, does it?
--
Michael Richardson , Sandelman So
a pretty normal process, yet it seems that some protocol designers
often do not take this in account. I wonder if we should write this down
as a BCP.
{the rest of what you wrote is great}
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PG
e PSK.
This sounds like a great idea. I will even agree to eat the pre-established
ASN.1 here. I had no preconceived notion as to the format, just that we have
a specific way to get the stuff in.
(I don't think, in a post-QM world, we can authenticate the EST with a
certificate though, but th
64, etc.
Simple stuff so that we can get a PPK from one machine (via sneaker-net) to
another machine without needing to write some perl to convert.
--
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
__
andard humen presentation format, such as bubble-babble [first hit:
http://www.wisegeek.com/what-is-bubble-babble.htm. Maybe there is a better
reference].
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
I found this:
http://wiki.yak.net/589/Bubble_Babble_Encoding.txt
probably never progressed into the IETF? Or maybe it's an RFC already :-)
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP sign
;> AUTH FAILUREs, or does that create too much of an oracle for testing
>> PPKs?
> I think it is better to keep the AUTHENTICATION_FAILURE to mean both,
> i.e., not provide an oracle.
okay, but can we determine the mismatch enough to log it?
--
Michael Richardson , Sand
clear before IKE_AUTH.
Good.
(I haven't spent the time to understand what the changes are to the math, and
it's been 10 years since I wrote that code, so please consider me a very
clueful end user in these discussions)
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT co
ext
> pseudonyms, so that would be bad idea if full protection is needed.
Is it reasonable to describe this Pseudonum update mechanism seperately, or
do you think it is too heavily connected to the quantum resistance
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
addresses. It's the whole MIF/split-horizon DNS problem, and I think it's
all a bad IPv4-specific idea, and we should be trying to kill it.
In an IPv6 world, we have better ways to build walled gardens.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
X is usually v4) in order to get v6 to my
laptop from coffee shops regularly. I haven't tried this over NAT64, but I
will change this to use DNS. Of course, I wouldn't need this tunnel in a
NAT64 network, since I'd have v6, so I'll setup some v4 IPsec too for the
next IETF and
e
> does not use the ID_KEYID of \x1c747c060d209a223d1f9f51b0351b54, but
> he uses the new ID_KEY_ID \x7ca765c1972372cecf78184d1a628d05 instead.
I can buy this.
It seems independantly useful to me.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.
y is going to use them.
I would like people to document an interface, but I have no desire to expose
it to users. In your Android example, I'm perfectly happy with having a
shell and a netlink/pfkey socket as the "interface".
--
Michael Richardson , Sandelman Sof
new Group PSK like we had with IKEv1.
> o Would we be happy with always negotiating a child SA (as none of the
> three proposals for stirring in the PPK attempt to protect the initial
> IKE SA)?
I wonder if this might be simpler and more reliable to just always do it, and
sp
they don't.
Isn't this "solved" by putting the security context in, and simply not
talking about it?We still tell users not to share keys, which is what we
plan to do anyway.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
Yoav Nir wrote:
> 4 Why do we need a new port? What goes wrong if the
> packets go to port 4500?
I think that TE/load-balancer in the network calculates the same tuple hash
and so takes the same path. (Presuming that it ignores the source UDP port)
--
Michael Richardson , San
Scott Fluhrer (sfluhrer) wrote:
>> Michael Richardson writes: > > - Authentication; if someone with a
>> Quantum Computer can break the DH > > in real time, do we care if he
>> can act as a man-in-the-middle? Scott > > Fluhrer: not important
scenario.
> - Authentication; if someone with a Quantum Computer can break the DH
> in real time, do we care if he can act as a man-in-the-middle? Scott
> Fluhrer: not important Michael Richardson: important, provided that we
> don't run into the same issues that IKEv1 PSKs ran i
Thank you for the reply, it helps me understand that AES-256 is worthwhile.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =- (Camping this week!)
signature.asc
Description: PGP signature
___
IPsec
qubit silicon gate" in 2016.
I believe that we need 128 to interact to break AES-128?
I'm just trying understand how the revolution that will take us from ~12
to 128, won't take us to 256 the following week.
I feel kinda like we are re-arranging the chairs on the titanic here.
--
rements (and my opinions); did I miss any
> requirement that you think is important? What are you opinions about
> these requirements?
We have to be able to negotiate to use of these extensions.
I want to suggest something further: that we might want to negotiate use
New charter seems fine.
(I am pessimistic about the milestones, but I suggest changing them as needed
rather than planning to take longer.)
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
AGGRESSIVE MODE message, we process until we
can see the ID, and then INVALID-MAJOR-VERSION?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
ht
that /56 and /60 are the suite spots)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| r
> ikev1-diediediediedie...
Yes, I would say so.
I'd even suggest that maybe it needs a CVE against products that have IKEv1
turned on by default.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Descri
do transfer sensitive information within IKE SA.
If the protection of the IKE SA means that we wind up in an IKEv1-like
situation with Main Mode and group PSKs, then the result will be that IKE is
not used.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
mitted one to avoid pre-distribution of the pad, but as
long as the attacker can record that, and eventually break the encryption
protecting sending the offset, then it fails.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Des
.
Perhaps this is worth a IKE 2.1 value --- an initiator that says 2.1
is saying that it will always put the COOKIE last.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec ma
supports (without adding a round trip to the
> protocol).
This is why I suggested... if you have to add a round trip anyway... might as
well solve a puzzle or something along the way.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting
new protocol was
quantum resistant, and *also* provided a measure of DDoS resistance, then
that would probably significantly improve the industry interest in it.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description:
So, this is different than "2048" and "4096".
This text would support a key length of 2304, for instance.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
__
you don't have actually do all of that
rekeying. You can simply look at the CRL, and if it turns out the key is
bad, you kill the SA, regardless of the PARENT SA lifetime.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signat
't know when to do another OCSP, so I think the recommendation is going to
be to set the CRL lifetime shorter.
--
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
Scott Fluhrer (sfluhrer) wrote:
>> From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Michael
>> Richardson
>>
>> It is my belief/memory that IKEv2 implementations should NOT limit SA
>> (PARENT or CHILD) lifetimes based upon certifi
x27;ve mis-remembered?
What document did I miss?
--
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
-SHA-something. I think it’s a prime candidate for MUST. CTR was
> always uncommon. ChaCha20+Poly1305 is so new that it can't be MUST this
> iteration. Maybe next time.
Agreed.
--
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
Yoav Nir wrote:
> “Some point” has arrived, and I don’t think group #2 should even be
> SHOULD- at this point.
MAY or SHOULD NOT?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP sig
ed ECDSA will show up too as a SHOULD+.
Does 3DES go to MAY?
Does SHA1 go to MUST-?
We hadn't listed SHA2 at all before.
We also have no GCM/CCM things specified.
Are we obligted to list them as SHOULD+ for awhile?
I think that the updates will otherwise be non-controversial.
--
Michael Ri
bout NTRU on wikipedia, of which I knew nothing before.
There are patents involved, I don't know which ones and I don't know when
they expire, but it seems like it isn't that new
an idea. Apparently they wrote some kind of exemption for open source.
--
Michael Richardson , Sandelman
rter, but it sure
would be nice to have a spec...
--
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
all the methods also use traditional DH, and IKEv2 defines ECDH methods
(AFAIK, haven't implemented yet).
I wonder if QC factoring of ECC easier than finding
SHA1/SHA2/etc. collisions, or if there is less effort being spent on the
secure hashes.
--
Michael Richardson , Sandelman Software
and the
> AES-256 encryption algorithm. RFC 2409 is the only version
> of the IKE standard that leverages symmetric pre-shared keys
> in a manner that may achieve quantum resistant confidentiality."
So, all of IKEv2 is out, according to them?
Or they just didn't con
solution is sutable for smartphones, however there are
> many weak clients that are not smartphones (besides IoT world
> that could be some SOHO devices, like sensors, home appliance,
> SOHO routers etc.).
It seems to me there can not be a one-size-fits all approach.
Focus on a sma
th the IPsec gateway, and given DHCP relays and multicast
destination addresses, the client doesn't even need to be configured)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
]
t on a generic operating system
(Linux, *BSD, probably windows), it's a problem to get the right bookeeping
in place.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec
very short packets (which might be keystrokes).
It also lets the sender send a NH=0 chaff packet with a bunch of padding so
that it looks like a real data.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
D
Yoav Nir wrote:
> Changes include:
> - Clarified keying material derivation for IKE
> - Calrified that IV is included in the Encrypted payload
> - Fixed the requirements for padding in the Encrypted payload so as not
to require padding bytes.
> - Added a paragraph on the (non
bet we even get an Errata filed :-)
The bit about ChaCha also being wrong would be useful to write down
somewhere.
--
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
d say
something like,
"According to cfrg-chacha20, Poly-1305 is not suitable for
use as a PRF for IKEv2, and this specification explicitely
does not allocate a code point for that."
=
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
th the concern that HMAC-SHA2/AES
might become weak, that it would seem odd to depend upon SHA2 as the PRF.
At least, users might not understand.
(noting that SHA2 != HMAC-SHA2, and also that the inputs to the PRF as not
very easily manipulated...)
--
Michael Richardson , Sandelman Software Works
ling to listen more to why it
makes sense. Are there actually IKE daemons that use the IPsec code to do
their decryption? I can see how this might happen in IoT space..
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
us (at least for IKE).
Whatever problems we have with an implicit IV in ESP will also be felt by DTLS.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ie
Y record to lookup which one to use. Does the remote want RSA or
> ECDSA? Well it will take some SPKI but you won't know until you're in
> IKE_AUTH (and they possibly rejected yours)
We have that problem right now: one could have RSA or DSA RR.
How is this any differen
e were to do anything, I'd say that we should create IPSECKEY algorithm
type 3, and say that it uses the same SubjectPublicKeyInfo minimal ASN.1
encoding that oop-pubkey uses.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardso
Meanwhile,there are IPsec vendors that run ESP over TCP in non-standard
fashions...)
I'd like to see some convergence at the dataplane side.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
hat the audit people think that knowing the version enables attacks,
as opposed to: knowing the version enables one to proactively repair things.
It seems like an argument for classifying encryption algorithms to me.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulti
rking around someone else’s
> mistakes.
Hahaha, that's really funny.
I guess you don't need to interop with anything you didn't buy.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
and only choice, and may lose
algorithm agility in protocols.}
I am supportive of defining code points for these.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec mail
e wrote on a typewriter in
the 1980s :-)
{In this case: bad guys need bigger computers to pull off bigger scams :-)}
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
IPsec ma
teway
can not perform MAC operations at wire speeds. For much of the life of the
IPsec specification, software implementations of IPsec have been slower than
line card speeds. It has only been in the past 7 to 9 years that this is
frequently not been the case; and it is still the case for mo
material needs to
> be transmitted also.
I left this here: I think that load balancers often *do* share private keys,
and I think this protocol could reduce this need.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
pgp35ZicLxjz2.pgp
Description:
) would do. {which raises
the question: why KINK isn't a better place for them to start}
As such, I don't see how this work can become "standard" for along time.
Maybe the bis-bis of it.
I am, however, all for accomodating the need for protocol numbers to make this
work
ing world...
So I buy your argument.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
pgpH58tKnxa9S.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
pgpDBYgvW1tkp.pgp
Description: PGP signature
___
think that we have the right people here to actually
get the work done in a way that would result in a deployed standard.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
pgpfhCcaHAa6Q.pgp
Description: PGP signature
___
IPsec
better strategy for the botnet, and I think
that we can more easily defend against.
So the goal here is to make sure that we select puzzles which drive the
botnet towards this.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael R
es very little budget for multi-processor botnet
communication. I suspect that this second part is impossible and/or easily
spoofed, as we don't know the actual RTT between client and gateway.
(Or rather, any RTT estimation could be spoofed by a botnet to give itself
more time)
--
Mich
have CPU left over for the collecting/sorting, and
of course, for other stuff like, say, IPsec...
I suspect, however, that the simplest machines to DDoS will be the smallest
gateways.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelma
think we need to think about the
problem deeper. It would be nice if it could be made to work; but I suspect
that may be equivalent to the CAPTCHA problem.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
pgpDnn8Gs1O51.pgp
Description: PGP
e algorithm according to the group’s preference and add
> a fast path for repeat visitors if we think that’s a good idea.
+1
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
pgpUcaL_6dADj.pgp
Description: PGP signature
_
f null-auth IKEv2,
followed by some non-null-auth once the two parties decide that they might
want to do something more interesting. (I liken this to two dogs sniffing
each other's butts... and then.. well. that might be safe-for-work)
I don't think IoT will be one of the situatio
ake the puzzle solving work charter.
I imagine that this is a real problem, but I wouldn't mind some data on how
often gateways are being DDoSed.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
pgpM1Y2GN5Yo_.pgp
Description: PGP signature
___
d, it didn't say that no identity was provided.
Clearly: the identity can't be trusted and can't be used in anyway.
So, given that, how does one look up acceptable TSx in the PAD?
I think that the opportunistic encryption use case given can not make a
aming is not a problem.
I prefer AUTH_NONE over "NULL AUTH".
Still, that doesn't convey enough intent; AUTH_DIDNTWANTTO, or something
like that might say it better, but that's a mouthful, so I can live with
AUTH_NONE if we can't do better.
--
Michael Richardson , S
da, and such an
>>argument is sure to come.
> Doing that on list would be possibly be more useful than waiting for
> the meeting. Or not.
Perhaps worth circulating the abandon email more widely around the IETF.
--
] Never tell me the odds! | i
itical* parties agree to come to the table. As
such, going forward with any standard which does not include those
parties takes a lot of effort, and, yet results in the same bad situation
that you mention.
I would rather one design.
--
] Never tell me the odds! | ipv6 me
had you a corporate laptop computer (any specs you like), for
you which you can not install any device drivers or do anything as root or
"administrator", can you install your VPN software?
Now, if I give you just enough root so that you can have a PF_KEY socket, can
you make som
ries (advpn draft and dmvpn) and real world experience
> (dmvpn), I would favor dmvpn, because the handling and operating sounds
less
> complex. (eg. lower amount of steps in tunnel initiation, single logical
> interface for tunnel termination etc.)
Do you care about mobile (h
Yaron & Paul, do you agree and if so can you give the authors some
> guidance on what you think would be most useful? E.g., have each
> proposal document how RFC7018's three use cases meet the 16+ RFC7108
> requirements, or something else?
Yes, please revise their
nalysis.
We will need mechanisms such as SIDR (RPKI) achieve the same level of
security with a layered approach as we have with star-topology based IKE.
And I'm still unclear which routing protocol lets routes for RTP traffic be
redirected, but not port-80 (or port-139!) traffic. So there
Frederic Detienne (fdetienn) wrote:
>> On 08 Dec 2013, at 12:08, "Michael Richardson"
wrote:
>>
>>
>> Frederic Detienne (fdetienn) wrote:
>>>> On 06 Dec 2013, at 19:41, Michael Richardson
wrote:
>>>> ...
Frederic Detienne (fdetienn) wrote:
> On 06 Dec 2013, at 19:41, Michael Richardson
wrote:
>> ...
>> I'd rather that you had mandated OSPFv2/3 or someso that I could
evaluate the
>> entire solution.
> The point is that we can't mandate
tity that has a similar solution?
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
pg
meso that I could evaluate the
entire solution.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
protocol would be the MTI
("IKE"/RFC4301!) , rather than being "well, whatever you like"
5) it permits port-specific policies to be controlled by HQ.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Soft
I prefer draft-sathyanarayan-ipsecme-advpn.
--
Michael Richardson , Sandelman Software Works
pgpN05woOnLIP.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
s, that part is
done in the routing algorithm.
--
Michael Richardson , Sandelman Software Works
pgpjpNRnmyo6i.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
d not find a suitable message type to convey dscp information.
> Can you suggest which notification message should be used here ?
Correct.
you'd have to write an ID on a new Notify type.
--
Michael Richardson , Sandelman Software Works
pgp8WS8Kt3_87.pgp
Descri
Tero Kivinen wrote:
> Michael Richardson writes:
>> For a given IPsec SA, they want to overwrite/force/set the DSCP to a
>> particular value. It will not depend upon the traffic goes into it
>> (but, the SPD selectors may quite specificly pick the traffi
the traffic goes into it
(but, the SPD selectors may quite specificly pick the traffic).
--
Michael Richardson , Sandelman Software Works
pgpMgR0C5d7B3.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailm
| ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
pgp76Mwuy2TMo.pgp
Description: PGP signature
___
IP
w that which AVP can be used?
> Your help will be appreciated.
> --
Does this thread help you:
http://www.ietf.org/mail-archive/web/ipsec/current/msg08740.html
Do you have the same problem as Paul?
--
Michael Richardson , Sandelman Software Works
pgp6Eaqh2qIRV.pgp
Descript
o. The "network" (i.e. the access
concentrator) needs to tell the UE located at the client/device what DS to
use on that network.
My suggestion is, since this is not something is subject to negotiation, that
simply defining a new notification value.
--
] Never tell
ccomplish this without
new kernel code.
--
Michael Richardson
-on the road-
--
Michael Richardson , Sandelman Software Works
pgpnCIB3fWIoJ.pgp
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
SHA1, use
> GHASH. So we no longer expect this to become a MUST in the future,
> hence the removal of the "+".
Within the IPsec community, I agree that this is the case, thank you for the
explanation.
--
] Never tell me the odds! | ipv6 mesh ne
201 - 300 of 397 matches
Mail list logo
