Jack Kohn writes:
> Do folks have to implement this RFC since its of the INFORMATIONAL
> type?
No, and same applies to WESP. You need either (or both) them only and
only if you operate in enviroments where they are suitable, and where
you require features provided by them.
> If Yes, then i would
Tero Kivinen wrote:
> pasi.ero...@nokia.com writes:
> > Paul Hoffman wrote:
> >
> > > >B.1 (Group 1): We may want to add: "Use of this group is NOT
> > > RECOMMENDED."
> > >
> > > Please open a tracker issue for this. Even though this is obvious,
> > > it is a tad late to be suggesting new normativ
Tero Kivinen wrote:
> > > What kind of things does the RFC require?
> >
> > Basically, it's assuming that even if you're running IKEv2 over IPv4
> > (and that IPv4 address is NATted), you can still negotiate transport
> > mode SAs for IPv6 addresses (which won't get NATted).
>
> Hmm Let m
Tero Kivinen wrote:
> > - Section 8.1: AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 are not
> > defined for IPsec ESP; these algorithms apply only to the
> > FiberChannel security protocols. So they should be removed from
> > this list (and since this was the only algorithm with 160-bit ICV,
> > handl
pasi.ero...@nokia.com writes:
> > --
> > 2.11. Address and Port Agility
> >
> >IKE runs over UDP ports 500 and 4500, and implicitly sets up ESP and
> >AH associations for the same IP addresses it runs over.
> > --
Hi Tero,
RFC 4555 Appendix A.2 has more text discussing this topic (when you
need to create a new ESP/AH SA, how do you know where to send the IKE
packets). It basically concluded this is beyond the scope of the spec,
and could be very simple (e.g. just configure a single IP address
somewhere), or
pasi.ero...@nokia.com writes:
> Tero Kivinen wrote:
>
> > > - Section 8.1: AUTH_HMAC_MD5_128 and AUTH_HMAC_SHA1_160 are not
> > > defined for IPsec ESP; these algorithms apply only to the
> > > FiberChannel security protocols. So they should be removed from
> > > this list (and since this was the
Hi all.
Combining Pasi's proposed text with Tero's comments I came up with this version.
Is this acceptable to everyone?
Yoav
There are couple of cases when a node receives a packet it cannot
process, but may want to notify the sender about this situation:
o If an ESP or AH packet ar
Hi all
The "offending" paragraph is the following;
An initiator can use port 4500, regardless whether or not there is
NAT, even at the beginning of IKE. When either side is using port
4500, sending with UDP encapsulation is not required, but
understanding received packets with UDP en
Tero Kivinen wrote:
> > > > - Section 2.1, suggesting that AH might have more bugs doesn't
> > > > sound
> > > > like an argument that belongs in this document.
> > >
> > > It was one of the arguments which was given when people said why
> > > they do not want to use AH.
> >
> > Nevertheless, as i
Alfred =?hp-roman8?B?SM5uZXM=?= writes:
> and later:
>
>[...] Routers MUST NOT drop
> packets merely because one or more of these reserved bits has a
> non-zero value.
This and Pasi's comments were strong enough, so I removed offending
check of
pasi.ero...@nokia.com writes:
> I'm OK with either one (but AH is a very stable and mature protocol,
> so while it's not as widely used, I would expect the level of testing
> has been quite substantial...).
I think I last tested AH in interop events in San-Diego interop 2000
or so. We might have d
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Maintenance and Extensions Working
Group of the IETF.
Title : Heuristics for Detecting ESP-NULL packets
Author(s) : T. Kivinen, D. McDonald
> Ok, I will send new one now (hopefully I do not need to update xml2rfc
> again this time, I did it already yesterday :-)
Thanks -- I've now asked the secretariat to start the IETF Last Call.
Best regards,
Pasi
___
IPsec mailing list
IPsec@ietf.org
htt
Yoav Nir writes:
> Is this acceptable to everyone?
Couple of comments.
>There are couple of cases when a node receives a packet it cannot
>process, but may want to notify the sender about this situation:
>
>o If an ESP or AH packet arrives with an unrecognized SPI, it
> could
The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'Heuristics for Detecting ESP-NULL packets '
as an Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this
hello
My name is suneel kumar,i want some information regarding dhcp over
ipsec,and functionality dhcp relay in a gateway
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
As the sender address isn't subscribed to the list, and has not been
confirmed earlier, we have to request a confirmation of the address.
To confirm the address, send a message to ip...@core3.amsl.com,
with the same subject line as this message.
___
IPsec
18 matches
Mail list logo
